Sortie de PostgreSQL 17.5, 16.9, 15.13, 14.18 et 13.21

Strasbourg/Mont-de-Marsan, le 9 mai 2025

Le PostgreSQL Global Development Group a publié le 8 mai une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 17.5, 16.9, 15.13, 14.18 et 13.21 . Cette mise à jour corrige une faille de sécurité et plus de 60 bugs remontés ces derniers mois. Pour la liste complète, voir les notes de version.

Annonce de fin de vie de PostgreSQL 13

PostgreSQL 13 ne recevra plus de mises à jour après le 13 novembre 2025. Si vous utilisez PostgreSQL 13 en production, nous vous conseillons de planifier la migration vers une version plus récente et supportée. Voir la politique de versionnement pour plus de détails.

Sécurité

CVE-2025-4207: La validation de l’encodage PostgreSQL GB18030 peut lire un octet au-delà la fin de l’allocation d’un texte.

CVSS v3.1 Base Score: 5.9

Versions supportées vulnérables : 13 à 17

Un dépassement de lecture lors de la validation de l’encodage PostgreSQL GB18030 permet à un fournisseur de données de déclencher un déni de service temporaires sur les plate-formes où un dépassement de 1 octet peut provoquer l’arrêt d’un processus. Cela concerne le serveur de base de données et la librairie libpq. Sont affectées les versions précédant PostgreSQL 17.5, 16.9, 15.13, 14.18 et 13.21.

Correctifs et améliorations

Cette mise à jour corrige plus de 60 bugs remontés ces derniers mois. Les problèmes ci-dessous concernent PostgreSQL 17. Certains peuvent concerner d’autres versions supportées.

• Gère correctement les clés étrangères auto-référentes sur les tables partitionnées. La création ou le rattachement de partitions ne créait pas les entrées adéquates dans le catalogue système pour une contrainte de clé étrangère, quand la table référencée par cette contrainte était la même table partitionnée. La conséquence était l’impossibilité de garantir la contrainte. Pour corriger cela, voir la partie « Mettre à jour ».

• Correction contre de potentielles pertes de données quand des index bloom BRIN sont utilisés (par exemple avec la classe d’opérateur date_bloom_ops).

• Corrige MERGE dans une table partitionnée avec les actions DO NOTHING.

• Prévient l’échec des commandes INSERT quand la table a une colonne générée (GENERATED) avec un domaine dont les contraintes interdisent les valeurs NULL.

• Corrige ALTER TABLE ... ADD COLUMN pour prendre en compte correctement un domaine avec sa propre valeur par défaut, quand DEFAULT n’est pas défini pour la colonne.

• Correction d’un problème de cast dans les clés d’expression de construction JSON.

• Corrige XMLSERIALIZE() pour que l’option INDENT soit correctement exportée quand elle est présente dans des vues ou règles. Ceci était visible sur les restaurations.

• Plusieurs corrections du planificateur de requêtes, incluant l’évitement d’une évaluation précoce d’arguments dans une fonction d’agrégat avec à la fois une clause FILTER et une clause ORDER BY ou DISTINCT, qui pouvaient entraîner des erreurs.

• Correction de résultats potentiellement incorrects quand un bitmap scan sans colonne de sortie est executé pendant qu’un vacuum est en cours sur la même table.

• Correction d’un problème de performance dans l’initialisation de la recherche des index GIN quand il y a beaucoup de clés de recherche, par exemple jsonbcol ?| array[...] avec des dizaines de milliers d’éléments dans le tableau.

• Garantit que les statistiques des I/O des WAL senders actifs sont rapportés sous une seconde au plus.

• Corrige une race condition dans la gestion de synchronous_standby_names juste après le démarrage, où un backend pouvait ne pas attendre un commit synchrone.

• Évite une boucle infinie si scram_iterations est mis à INT_MAX.

• Plusieurs correctifs en réplication logique, incluant la gestion du vacuum autour de lignes effacées encore nécessaires au décodage logique.

• Évite de potentielles pertes de données lorsque des ordres de modification de schéma (DDL) sans verrou fort concernent des tables répliquées logiquement.

• Évite des soucis en réplication logique pouvant mener à ce que des données soit appliquées en double, à cause de la gestion d’erreur de l’apply worker.

• Améliore la gestion des réindexations parallèles pour atteindre le niveau de parallélisation attendu.

Cette version met aussi à jour les fichiers tzdata sur les fuseaux horaires à la version 2025b, concernant les changements législatifs d’heure d’été au Chili, et des corrections historiques pour l’Iran. De plus, il apparaît un nouveau fuseau horaire America/Coyhaique pour la région chilienne de Aysén, qui reste à UTC-03 toute l’année, ce qui diffère d’America/Santiago.

Mettre à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Comme pour les autres versions mineures, les utilisateurs n’ont pas besoin de sauvegarder et recharger leur base de données, ni d’utiliser pg_upgrade pour appliquer la mise à jour. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Si vous aviez créé une clé étrangère autoréférente sur une table partitionnée, vous devez, après la mise à jour, supprimer et recréer ces clés étrangères autoréférentes, si des partitions ont été créés ou rattachés depuis la création de la contrainte. Il pourrait y avoir des lignes la violant ; auquel cas la recréation échouera, et vous devrez corriger les lignes et recommencer.

Les utilisateurs n’ayant pas appliqué toutes les mises à jour précédentes doivent vérifier qu’il n’y pas d’opérations supplémentaires nécessaires après ces mises à jour. Pour s’en assurer, consulter les notes de version précédentes pour les détails.

Liens

• Téléchargements
• Notes de version
• Sécurité
• Politique de versionnement
• Donnez