PostgreSQL 17.5 et autres correctifs

2025-05-13

893 mots, 5 minutes de lecture

Le PGDG (PostgreSQL Global Development Group) a publié une mise à jour de toutes les versions supportées de PostgreSQL, incluant 17.5, 16.9, 15.13, 14.18 et 13.21.

Cette publication corrige également une vulnérabilité de sécurité et plus de 60 bogues reportés dans les mois précédents.

Fin du support de la version 13 de PostgreSQL

La version 13 de PostgreSQL ne recevra plus de correctifs à partir du 13 novembre 2025. Il est donc recommandé de mettre à jour vers une version majeure vos instances en production. Se référer à la note de versions pour plus d’informations.

Problèmes de sécurité

CVE-2025-4207 :
- CVSS v3.1 Base Score: 5.9
- Supported, Vulnerable Versions: 13 - 17.

Lors de l’utilisation de l’encodage GB18030 (encodage officiel chinois), il est possible à un attaquant d’effectuer une lecture au-delà du tampon de validation de cet encodage. Cette lecture provoque un arrêt du processus et induit un déni de service temporaire. Cette vulnérabilité concerne le serveur de bases de données PotgreSQL et la bibliothèque libpq. Les versions antérieures à PostgreSQL 17.5, 16.9, 15.13, 14.18, et 13.21 sont affectées.

Corrections de bogues et améliorations

Cette mise à jour corrige plus de 60 bogues ayant été signalés durant les mois précédents. Les problèmes ci-dessous concernent PostgreSQL 17. Certains de ces problèmes peuvent aussi concerner d’autres versions de PostgreSQL.

Les correctifs sont :

gestion correcte des clés étrangères autoréférentielles sur les tables partitionnées. La création ou l’attachement d’une partition ne créait pas les entrées de catalogue requises pour une contrainte de clé étrangère si la table référencée par la contrainte était la même table partitionnée. Il en résultait que la contrainte pouvait ne pas être respectée. Pour corriger ce problème, veuillez consulter les instructions de la section « Mise à jour » ;
correction d’un problème de perte de données lors de l’utilisation d’index BRIN bloom (en utilisant par exemple la classe d’opérateur date_bloom_ops) ;
correction de MERGE dans une table partitionnée avec des actions DO NOTHING ;
prévention de l’échec des commandes INSERT lorsque la table possède une colonne GENERATED d’un type de domaine et que les contraintes du domaine interdisent les valeurs NULL ;
correction de la commande ALTER TABLE ... ADD COLUMN pour gérer correctement le cas d’un type de domaine qui a sa propre valeur par défaut et que la valeur DEFAULT pour la colonne n’est pas définie.
correction de problèmes lors de conversion de types dans les clés des expressions de constructeurs JSON ;
correction de XMLSERIALIZE() pour que l’option INDENT soit correctement supprimée lorsqu’elle est présente dans les vues ou les règles. Ceci était perceptible lors de restaurations ;
corrections pour le planificateur de requêtes, évitant l’évaluation prématurée des arguments dans une fonction d’agrégation ayant à la fois des clauses FILTER et ORDER BY ou DISTINCT qui pourraient conduire à des échecs ;
correction sur le retour de résultats incorrects lors d’un bitmap scan sans colonnes de sortie qui est exécuté alors que vacuum est également en cours d’exécution sur la même table ;
correction des problèmes de performance dans le démarrage de la recherche d’index GIN lorsqu’il y a beaucoup de clés de recherche, par exemple, jsonbcol ?| array[...] avec des dizaines de milliers d’éléments dans la liste ;
s’assurer que les statistiques d’E/S des WAL senders actifs soient rapportées dans un délai maximum d’une seconde ;
correction d’une condition de concurrence dans la gestion de synchronous_standby_names immédiatement après le démarrage, où un backend pourrait ne pas attendre un commit synchrone ;
éviter une boucle infinie si scram_iterations est fixé à INT_MAX.
corrections pour la réplication logique, y compris la gestion de vacuum autour des lignes supprimées qui sont toujours nécessaires pour le décodage logique ;
prévention des pertes de données potentielles lorsque des opérations de modification de schéma (DDL) qui ne prennent pas de verrous forts affectent des tables qui sont répliquées logiquement ;
prévenir les problèmes dans la réplication logique qui pourraient permettre l’enregistrement de données dupliquées en raison de la gestion des erreurs du apply worker ;
amélioration de la manière dont reindexdb gère la planification des opérations de réindexation parallèle afin d’obtenir le niveau de parallélisme attendu ;

Cette version met également à jour les fichiers de données de fuseaux horaires avec la version 2025b de tzdata pour les changements de loi de l’heure d’été au Chili, ainsi que des corrections historiques pour l’Iran. En outre, un nouveau fuseau horaire America/Coyhaique a été créé pour la région d’Aysén au Chili, afin de tenir compte du fait qu’elle passe à UTC-03 tout au long de l’année, ce qui diverge d'America/Santiago.

Mise à jour

Toutes les publications de mises à jour de PostgreSQL sont cumulatives. Comme pour les autres mises à jour mineures, il n’est pas nécessaire d’extraire et de recharger les bases de données ni d’utiliser pg_upgrade pour appliquer cette mise à jour ; il suffit simplement d’arrêter PostgreSQL et de mettre à jour les binaires.

Les utilisateurs ayant sauté une ou plusieurs mises à jour peuvent avoir besoin d’étapes additionnelles après la mise à jour. Les notes de publication des versions précédentes fournissent les détails.

Pour plus de détails, se référer à la note de publication de versions.

Liens