Sortie de PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25 et 19 RC 2

Publié le 12/11/2026 par Robin PORTIGLIATTI, Alain LESAGE

Paris, le 12 novembre 2026

Le PostgreSQL Global Development Group a publié le 12 novembre une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.7, 17.12, 16.16, 15.20 et 14.25, ainsi que la deuxième release candidate de PostgreSQL 19. Cette mise à jour corrige 52 failles de sécurité et plus de 140 bugs signalés au cours des derniers mois.

Plusieurs problèmes peuvent nécessiter des actions supplémentaires après la mise à jour ; ils sont décrits en détail ci-dessous. Consultez la section « Mise à jour » pour connaître les opérations à réaliser après la mise à jour.

Pour la liste complète, voir les Notes de version.

visuel annonce

Fin de vie de PostgreSQL 14

Cette version est la dernière de PostgreSQL 14. PostgreSQL 14 est désormais en fin de vie et ne recevra plus de correctifs de sécurité ou de bugs. Si vous utilisez PostgreSQL 14 en production, nous vous suggérons de planifier une migration vers une version plus récente et supportée de PostgreSQL. Veuillez consulter notre politique de versionnement pour plus d’informations.

Problèmes de sécurité

Les failles de sécurité corrigées par cette mise à jour sont les suivantes, les liens ci-dessous donnent plus de détails sur chaque faille et sur les versions concernées :

  • CVE-2026-6460 : une confusion de type après ALTER ... SET DATA TYPE permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-6467 : une mauvaise gestion du schéma dans les scripts d’extension permet l’exécution de SQL arbitraire (CVSS v3.1 : 7.2)
  • CVE-2026-14661 : dblink et les souscriptions peuvent ajouter des données à la fin de fichiers arbitraires (CVSS v3.1 : 8.1)
  • CVE-2026-16237 : INSERT ... ON CONFLICT peut lire ou modifier des lignes malgré la condition WHERE d’une vue modifiable automatiquement (CVSS v3.1 : 5.4)
  • CVE-2026-16240 : pg_basebackup peut utiliser le contenu du manifeste de sauvegarde comme format de chaîne de caractères (CVSS v3.1 : 3.7)
  • CVE-2026-18447 : une confusion de type sur un paramètre de sortie permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116303 : les conversions liées aux clés étrangères et à JSON contournent le droit EXECUTE sur les fonctions de transtypage (CVSS v3.1 : 3.1)
  • CVE-2026-116304 : une utilisation de mémoire déjà libérée (use-after-free) sur le typmod d’un RECORD en parallélisme permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116306 : la modification d’un type composite pendant l’affectation d’un champ permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116307 : un use-after-free sur les requêtes préparées de plperl permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116308 : dict_int lit au-delà des lexèmes de longueur nulle (CVSS v3.1 : 4.3)
  • CVE-2026-116309 : une confusion de type sur les références « bénies » (blessed) de plperl peut permettre l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116310 : le contexte d’erreur de COPY utilise une zone de stockage de champ déjà libérée (CVSS v3.1 : 4.3)
  • CVE-2026-116311 : DROP OWNED peut supprimer des politiques restrictives de sécurité au niveau ligne sur des tables dont le rôle n’est pas propriétaire (CVSS v3.1 : 5.4)
  • CVE-2026-116312 : MERGE peut placer la mauvaise ligne dans une table de transition de trigger (CVSS v3.1 : 5.4)
  • CVE-2026-116313 : vacuumdb --missing-stats-only permet au propriétaire d’une base d’exécuter du code en tant que l’utilisateur lançant vacuumdb (CVSS v3.1 : 7.2)
  • CVE-2026-116314 : pg_restore exécute du code arbitraire en raison d’une validation manquante des archives qui ne sont pas au format texte (CVSS v3.1 : 8.8)
  • CVE-2026-116315 : un dépassement de tampon sur le tas dans tsvector_delete() permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116316 : les opérations à sécurité restreinte peuvent créer dans pg_temp des types que les requêtes suivantes de la session trouvent (CVSS v3.1 : 8.8)
  • CVE-2026-116317 : un dépassement de tampon sur le tas dans ts_rank_cd() peut permettre l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116318 : dans pg_dump, le nom d’une contrainte NOT NULL permet une injection SQL (CVSS v3.1 : 8.8)
  • CVE-2026-116319 : un use-after-free lors d’un appel réentrant à return_next() dans plperl permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116320 : un use-after-free dans la conversion des tableaux et des hachages de plperl permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116321 : une valeur de type name non terminée divulgue le contenu de la mémoire du serveur (CVSS v3.1 : 4.3)
  • CVE-2026-116322 : une demande d’annulation avant authentification peut laisser un spinlock non relâché (CVSS v3.1 : 5.3)
  • CVE-2026-116323 : un use-after-free lors d’une conversion réentrante de résultat dans pltcl permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116325 : la mise entre guillemets des noms d’index par reindexdb permet une injection SQL (CVSS v3.1 : 8)
  • CVE-2026-116326 : les exceptions des objets liés (tied) de plperl suivent un sigjmp_buf périmé (CVSS v3.1 : 8.8)
  • CVE-2026-116327 : l’analyse de security_barrier peut exposer des valeurs cachées au travers d’expressions indirectes (CVSS v3.1 : 4.3)
  • CVE-2026-116328 : un dépassement d’entier dans le contexte mémoire Generation permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116329 : une confusion de type lors de l’import de statistiques permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116330 : le fichier restore.sql d’une archive tar de pg_dump ne bloque pas l’injection de commandes psql (CVSS v3.1 : 8.8)
  • CVE-2026-116331 : une confusion de type dans les agrégats min/max permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116332 : un use-after-free lors de la mise en place d’un portail (requêtes préparées) permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116333 : un parcours parallèle d’index B-tree sur un tableau de valeurs lit au-delà des limites du tableau (CVSS v3.1 : 6.5)
  • CVE-2026-116335 : une confusion sur le type de résultat d’un commutateur ou d’un négateur permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-116336 : REINDEX CONCURRENTLY ne bloque pas DROP INDEX pendant l’exécution des fonctions d’index (CVSS v3.1 : 8.8)
  • CVE-2026-120139 : un dépassement d’entier sur la taille des lignes permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120141 : une confusion de type sur une fonction matérialisée renvoyant un ensemble permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120142 : une confusion de type sur une colonne supprimée permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120143 : un use-after-free sur un curseur de table de transition permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120144 : un défaut d’invalidation du cache de types permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120145 : la réplication logique peut écrire dans les catalogues système de l’abonné, ce qui permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120146 : REASSIGN OWNED contourne les vérifications SET et CREATEDB sur les rôles (CVSS v3.1 : 4.3)
  • CVE-2026-120147 : un use-after-free lors d’une déconnexion réentrante de dblink permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120148 : une confusion de pseudo-type dans les statistiques étendues permet l’exécution de code arbitraire (CVSS v3.1 : 8.1)
  • CVE-2026-120149 : une incohérence dans l’insertion par lots d’un FDW permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120150 : un use-after-free lors de la vérification de domaine d’un enregistrement étendu (expanded record) permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120151 : une confusion de type sur un champ d’enregistrement en plpgsql permet l’exécution de code arbitraire (CVSS v3.1 : 8.8)
  • CVE-2026-120152 : un use-after-free dans pg_show_all_settings() divulgue de la mémoire (CVSS v3.1 : 4.3)
  • CVE-2026-120153 : les substitutions dans les scripts d’extension permettent une injection SQL au travers des noms d’objets (CVSS v3.1 : 7.2)
  • CVE-2026-120154 : INSERT ... ON CONFLICT peut lire des lignes malgré les politiques de sécurité au niveau ligne (RLS) (CVSS v3.1 : 4.3)

Corrections de bugs et améliorations

Cette mise à jour corrige plus de 140 bugs signalés au cours des derniers mois. Les problèmes listés ci-dessous concernent PostgreSQL 18. Beaucoup d’entre eux touchent également les autres versions supportées de PostgreSQL.

  • Correction de l’export et de l’import d’instantanés (snapshots) pris sur un serveur secondaire. Le problème a été détecté lors d’un pg_dump parallélisé lancé sur un secondaire, et pouvait corrompre à la fois la sauvegarde produite et les données du secondaire. Plus généralement, une transaction important un instantané pris sur un secondaire pouvait renvoyer des résultats erronés.
  • Plusieurs corrections sur les index GIN, qui pouvaient mener à une corruption de l’index : des requêtes manquaient alors des lignes ou renvoyaient des lignes sans rapport. Si vous soupçonnez qu’un index GIN est touché, vous devriez le réindexer. Consultez les notes de version pour plus de détails sur le problème, et la section « Mise à jour » pour les opérations à réaliser après la mise à jour.
  • Correction d’une corruption possible des index GiST de pg_trgm, qui pouvait faire manquer des lignes aux recherches. Une réindexation est nécessaire après la mise à jour ; voir la section « Mise à jour ».
  • Correction d’un cas où, après la reconstruction par REINDEX CONCURRENTLY d’un index d’une table TOAST, des mises à jour ultérieures de l’index pouvaient être perdues, ce qui provoquait des erreurs missing chunk number. Si vous avez rencontré ce problème, il faudra réindexer après la mise à jour. Voir la section « Mise à jour ».
  • Interdiction des contraintes NOT NULL NO INHERIT sur les tables partitionnées dans tous les cas, y compris avec CREATE TABLE ... LIKE. Auparavant, une partition pouvait ainsi contenir des valeurs NULL alors qu’elle n’aurait pas dû. La section « Mise à jour » indique comment trouver et réparer les contraintes concernées.
  • Désactivation de la déduplication des index B-tree pour les colonnes déclarées en bpchar sans longueur, qui pouvait fausser les résultats des parcours d’index seul (index-only scans). Si vous avez des index B-tree sur des colonnes bpchar, vous devriez les réindexer après la mise à jour. Voir la section « Mise à jour ».
  • Plusieurs corrections sur les sauvegardes incrémentales, qui pouvaient produire des sauvegardes corrompues. Nous recommandons de réaliser une nouvelle sauvegarde complète après la mise à jour et de l’utiliser pour les sauvegardes incrémentales suivantes. Voir la section « Mise à jour ».
  • Plusieurs corrections sur les sauvegardes de base (base backups), dont la prévention d’une copie incohérente du fichier pg_control et de copies tronquées ou complétées par des zéros de fichiers comme postgresql.auto.conf, remplacés pendant la sauvegarde.
  • Refonte de l’implémentation de la suppression de jointures dans le planificateur. Il s’agit d’un changement important pour une version mineure, réalisé pour mettre fin aux bugs à répétition de l’implémentation précédente.
  • Correction d’une perte possible de lignes pendant la réécriture d’une table (par exemple CLUSTER ou VACUUM FULL) lorsqu’une ligne avait été mise à jour par une sous-transaction ensuite annulée.
  • Correction des durées d’entrées/sorties rapportées par le VACUUM parallélisé.
  • Plusieurs corrections de problèmes pouvant causer une perte ou une incohérence de données après un crash, notamment le démarrage d’un checkpoint pendant la création d’un multixact ou pendant l’annulation d’une transaction préparée. Cette version écrit aussi de manière atomique les fichiers d’état des transactions préparées en attente : un crash pouvait auparavant laisser un fichier invalide qui empêchait le serveur de démarrer.
  • Plusieurs corrections dans le planificateur, qui pouvait produire des résultats erronés, notamment pour les requêtes avec des références LATERAL, des jointures externes, l’élimination d’auto-jointures sur des tables utilisant l’héritage, un DISTINCT ON dans une sous-requête avec des fonctions renvoyant des ensembles, et les requêtes utilisant des collations non déterministes.
  • Plusieurs corrections sur l’élagage des partitions (partition pruning), qui pouvait faire manquer des lignes, notamment pour les tables partitionnées par RANGE sur plusieurs colonnes quand une requête ne filtre que sur les premières colonnes, pour les partitions DEFAULT de tables utilisant les bornes MINVALUE ou MAXVALUE, et pour des mises à jour concurrentes qui pouvaient ignorer silencieusement des lignes à mettre à jour.
  • Correction d’INSERT ... ON CONFLICT pour acquérir un verrou de prédicat sur la ligne en conflit en isolation SERIALIZABLE. Auparavant, des mises à jour concurrentes qui auraient dû échouer avec une erreur de sérialisation pouvaient réussir.
  • Correction de MERGE avec WHEN NOT MATCHED BY SOURCE lorsque la ligne cible est supprimée de manière concurrente. Auparavant, une action WHEN NOT MATCHED BY TARGET pouvait être exécutée à la place, donnant des résultats incorrects.
  • Plusieurs corrections sur les fonctions SQL/JSON comme JSON_TABLE et JSON_VALUE, qui pouvaient renvoyer des résultats incorrects.
  • Plusieurs corrections sur la réplication logique, où un abonné pouvait appliquer des modifications de manière incorrecte.
  • Plusieurs corrections sur les serveurs secondaires, évitant notamment des retards de rejeu et des annulations de requêtes inutiles dans certains cas.
  • Correction de psql pour accepter plusieurs commandes COPY ... FROM STDIN dans une même chaîne de commandes. Le correctif de CVE-2026-6464 amenait psql à les rejeter.
  • Plusieurs corrections de problèmes pouvant empêcher la restauration d’une sauvegarde logique, ou amener une vue restaurée à se comporter différemment de l’originale. Sont concernées les vues et règles utilisant AT TIME ZONE dans une clause FROM ou un alias de cible nommé set, ainsi que des valeurs tsvector et tsquery qui pouvaient ne pas se recharger.
  • Correction d’un blocage du serveur, au lieu d’un arrêt, lorsque le processus de démarrage (startup) plante pendant que le serveur redémarre après un crash.

Cette version met également à jour les fichiers de fuseaux horaires vers la version 2026f de tzdata. À partir de novembre 2026, les Territoires du Nord-Ouest du Canada (America/Inuvik) restent toute l’année à UTC-06 et le Manitoba (America/Winnipeg) toute l’année à UTC-05. Cette version suppose que leurs abréviations de fuseau seront respectivement CST et EST (ce qui pourrait changer). Elle tient aussi compte du maintien de Cuba à l’heure d’été cet hiver, et du fait que les noms de zones EST5EDT, CST6CDT, MST7MDT et PST8PDT utilisent désormais, pour les anciens horodatages, le décalage UTC qu’ils indiquent plutôt que l’historique de la zone nommée d’après une ville qui leur est associée.

Mise à jour

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

Si vous soupçonnez qu’un index GIN est touché par l’un des problèmes de corruption corrigés dans cette version, vous devriez le réindexer, par exemple :

REINDEX INDEX nom_de_votre_index;

Si vous utilisez pg_trgm, vous devriez réindexer tous les index GiST utilisant la classe d’opérateurs gist_trgm_ops.

Si vous rencontrez des erreurs missing chunk number à la lecture d’une table, vous devriez réindexer la table, ce qui réindexe aussi sa table TOAST, par exemple :

REINDEX TABLE nom_de_votre_table;

Si vous utilisez les sauvegardes incrémentales, nous recommandons de réaliser une nouvelle sauvegarde complète après la mise à jour et de la prendre comme base des sauvegardes incrémentales suivantes.

Si vous utilisez des tables partitionnées, la requête suivante trouve les contraintes NOT NULL NO INHERIT posées sur des tables partitionnées :

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

Vous pouvez supprimer les contraintes indésirables avec ALTER TABLE ... DROP CONSTRAINT .... Les contraintes à conserver doivent être réparées avec ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, qui échouera si l’une des partitions de la table contient des valeurs NULL dans cette colonne.

Si vous avez des index B-tree sur des colonnes bpchar (c’est-à-dire des colonnes déclarées en bpchar sans longueur), vous devriez les réindexer après la mise à jour. Les colonnes déclarées en char(n) ne sont pas concernées.

Les utilisateurs ayant sauté une ou plusieurs mises à jour mineures peuvent avoir à réaliser des opérations supplémentaires après la mise à jour ; veuillez consulter les notes de version des versions précédentes pour les détails.

Pour plus de détails, veuillez consulter les notes de version.

Note sur PostgreSQL 19 RC 2

Cette publication constitue la deuxième release candidate de PostgreSQL 19. En tant que release candidate, PostgreSQL 19 RC 2 sera en grande partie identique à la version initiale de PostgreSQL 19, même si d’autres correctifs pourront encore être appliqués avant la disponibilité générale de PostgreSQL 19. PostgreSQL 19 RC 2 inclut aussi les correctifs de cette mise à jour mineure qui s’appliquent à PostgreSQL 19.

La date prévue pour la disponibilité générale de PostgreSQL 19 est le 19 novembre 2026. Voir la section « Calendrier de sortie » pour plus de détails.

Migration vers PostgreSQL 19 RC 2

Pour migrer vers PostgreSQL 19 RC 2 depuis une version antérieure de PostgreSQL, il faut utiliser une stratégie de mise à jour majeure, par exemple pg_upgrade ou pg_dump / pg_restore. Pour plus d’informations, consultez la section de la documentation sur les mises à jour :

https://www.postgresql.org/docs/19/upgrading.html

Si vous utilisez pg_upgrade et que vous avez des index utilisant la recherche plein texte, pg_trgm ou fuzzystrmatch, veuillez lire la section « Migration to Version 19 » des notes de version : il peut être nécessaire de les réindexer après la migration.

Changements depuis la RC 1

Plusieurs corrections de bugs ont été appliquées à PostgreSQL 19 pendant la période de la RC 1, parmi lesquelles :

  • Retrait d’un changement qui permettait d’utiliser des expressions JSON_ARRAY() et JSON_OBJECT() portant sur des tableaux, des types composites et des types d’intervalle (range) dans les index sur expression, les colonnes générées et les clés de partitionnement : ces index pouvaient devenir obsolètes. Si vous avez créé de tels objets en testant PostgreSQL 19, vous devez les supprimer ou les redéfinir avant la migration : pg_dump / pg_restore et pg_upgrade échoueront à les recréer.
  • Correction de résultats erronés dans les requêtes GROUPING SETS, où une colonne absente de l’ensemble de regroupement courant pouvait afficher une valeur au lieu de NULL.
  • Correction d’une boucle infinie dans first_value() et nth_value() avec IGNORE NULLS et certaines options EXCLUDE de la fenêtre.
  • Correction de l’agrégation anticipée (eager aggregation), qui exécutait les fonctions volatiles d’une condition de jointure une fois par groupe au lieu d’une fois par ligne.
  • Correction d’une attente infinie lors de la promotion d’un serveur secondaire si une session est bloquée sur l’envoi de données à un client qui a cessé de lire.
  • Correction d’un blocage de la file LISTEN / NOTIFY si une session est interrompue pendant la lecture des notifications.
  • Correction de vérifications de clés étrangères qui pouvaient échouer avec une erreur lorsque le type de la colonne référençante nécessite un transtypage pour être comparé à la colonne référencée.
  • Correction de régressions de performance dans l’exécution de requêtes à base de hachage, dont des tables de hachage qui pouvaient être dimensionnées bien au-delà de la limite work_mem à partir de l’estimation du nombre de lignes par le planificateur.

Pour une liste détaillée des corrections, consultez la page des points ouverts.

Calendrier de sortie

Il s’agit de la deuxième release candidate de PostgreSQL 19. Sauf découverte d’un problème imposant un report ou une release candidate supplémentaire, PostgreSQL 19 devrait être disponible le 19 novembre 2026.

Pour plus d’informations, consultez la page Beta Testing.

Liens

DALIBO

DALIBO est le spécialiste français de PostgreSQL®. Nous proposons du support, de la formation et du conseil depuis 2005.