Brive La Gaillarde, le 13 août 2026

Le PostgreSQL Global Development Group a publié le 13 août une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.6, 17.11, 16.15, 15.19, 14.24. Cette mise à jour corrige 28 vulnérabilités de sécurité et plus de 110 bugs. Cette mise à jour saute une version mineure de PostgreSQL 18, passant de la 18.4 à la 18.6. La version 18.5 n’a pas vu le jour suite à un problème de régression.

Après la mise à jour, trois points peuvent nécessiter des opérations supplémentaires décrites plus bas. Ce sont :

  • la création parallélisée des index GIN
  • btree_gist
  • ltree

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

visuel annonce

Annonce de fin de vie de PostgreSQL 14

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

Failles de sécurité

CVE-2026-6464: Un échec précoce de COPY FROM STDIN dans psql traite les lignes de données comme des commandes psql

CVSS v3.1 Base Score: 8.1
Versions vulnérables : 14 - 18.
L’inclusion de données non fiables dans la commande COPY de psql peut permettre à un administrateur du serveur de provoquer l’exécution de lignes de données en tant que commandes psql, via une injection d’erreur. Si la commande COPY FROM STDIN ou \copy FROM STDIN échoue avant que le serveur n’indique qu’il attend des lignes en entrée, psql traite les lignes de données intégrées au script comme des commandes psql. Un COPY FROM avec un nom de fichier n’est pas concerné. L’administrateur du serveur n’a pas de contrôle intrinsèque sur les lignes de données, une attaque complète nécessite donc que l’attaquant prenne le contrôle à la fois du serveur et des lignes à charger. Ou encore, un attaquant contrôlant uniquement ces lignes pourrait parvenir à ses fins à la faveur d’une erreur fortuite. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6469: La commande ALTER TABLE ALTER TYPE réinitialise le propriétaire des statistiques étendues

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14 - 18.
Dans la commande ALTER TABLE ALTER TYPE, une affectation incorrecte du propriétaire réattribue à l’utilisateur courant la propriété des objets statistiques dépendants. Cela autorise à tort le propriétaire de la table à exécuter les commandes DROP STATISTICS et ALTER STATISTICS, et les interdit à tort au propriétaire précédent. La commande DROP TABLE reste capable de supprimer les objets statistiques, donc cette faille n’a aucun effet dans de nombreux cas de figure. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6470: PostgreSQL ne vérifie pas le droit USAGE sur un type

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une autorisation manque dans les commandes DDL de PostgreSQL. Le créateur d’un objet peut alors créer une dépendance sur un type, et, via les commandes ALTER et DROP du type provoquer un déni de service. La plupart des opérations DDL vérifiaient bien ce droit, mais deux d’entre elles ne le faisaient pas : l’affectation d’un sous-type de range, et le référencement du type depuis une expression SQL. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6471: Le décodage logique de PostgreSQL peut charger un fichier arbitraire via dlopen

CVSS v3.1 Base Score: 7.2
Versions vulnérables : 14 - 18.
Une autorisation est manquante dans le décodage logique de PostgreSQL. Un utilisateur non superutilisateur disposant du droit REPLICATION peut alors charger, via dlopen, n’importe quel fichier visible depuis le compte système sous lequel s’exécute le serveur, en choisissant le bon plugin de décodage logique, et ensuite d’exécuter du code arbitraire sous ce compte. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14662: Les types tsvector et tsquery sous-dimensionnent des allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Dans les fonctions concernant les types de données tsvector et tsquery, un débordement d’entier permet à un utilisateur non privilégié de forcer le serveur à sous-dimensionner une allocation et à écrire hors limites, via des entrées volumineuses spécialement conçues. Il peut alors exécuter un code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Ces types proviennent généralement de la logique applicative et non des utilisateurs de l’application : une attaque menée par un utilisateur final en utilisant l’application comme relai est donc peu probable. La CVE-2026-6473 avait corrigé des problèmes similaires. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14663: pgcrypto chiffre et déchiffre silencieusement en clair pour les algorithmes de chiffrement désactivés par OpenSSL

CVSS v3.1 Base Score: 6.5
Versions vulnérables : 14 - 18.
Le stockage en clair opéré par pgcrypto pour les algorithmes de chiffrement désactivés permet aux utilisateurs de récupérer les données en clair, par lecture directe du texte chiffré défectueux. La version d’OpenSSL et sa configuration déterminent les algorithmes désactivés. Si l’application accepte des données chiffrées en entrée, le déchiffrement réussira même avec une mauvaise clé. Cela fait perdre la modeste protection apportée par le Modification Detection Code (MDC). Les fonctions concernées sont pgp_sym_encrypt, pgp_sym_decrypt, pgp_pub_encrypt, pgp_pub_decrypt, pgp_sym_encrypt_bytea, pgp_sym_decrypt_bytea, pgp_pub_encrypt_bytea et pgp_pub_decrypt_bytea. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14664: Un dépassement de heap buffer permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans le moteur d’expressions rationnelles de PostgreSQL permet à l’auteur d’une requête d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via un texte qui ne passerait pas la validation d’encodage. Ce problème est de la même famille que la CVE-2026-2006, mais il implique ici une croissance non prévue des données lors d’un aller-retour à travers pg_wchar. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14666: Le cache du row level security ignore les modifications des rôles

CVSS v3.1 Base Score: 4.2
Versions vulnérables : 14 - 18.
Le suivi des modifications d’appartenance à un rôle, des attributs de rôle et de la propriété des bases est incomplet. Une requête peut ainsi continuer à utiliser des règles de row level security mises en cache alors que ces changements imposent désormais d’autres règles, via la réutilisation du plan. Les politiques obsolètes restent en vigueur jusqu’à ce qu’un autre évènement invalide le cache ou que la session se termine. L’utilisateur peut alors réaliser des lectures et modifications encore récemment autorisées, mais désormais interdites. L’attaquant doit adapter son attaque au schéma de retrait de droits et aux politiques de sécurité propres aux rôles de l’application visée. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14668: Une confusion de type ctid dans l’estimation de sélectivité divulgue une dérivée de lecture arbitraire

CVSS v3.1 Base Score: 8.1
Versions vulnérables : 14 - 18.
À cause d’un mélange de type dans l’entrée de l’estimation de sélectivité du type ctid de PostgreSQL, le créateur d’un objet peut consulter un calcul dérivé de la valeur d’une portion arbitraire de 4 octets de la mémoire, via une entrée choisie qui n’est pas de type ctid. Bien que le calcul perde en précision, la récupération d’une part substantielle des valeurs en mémoire semble possible. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14669: Un dépassement de heap buffer dans to_char permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans to_char(timestamptz) permet à la partie qui choisit le fuseau horaire d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, en utilisant une abréviation de fuseau horaire POSIX long. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14670: Un dépassement de heap buffer sur les objets liés en plperl permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer au retour d’une table de hachage liée (tied hash) en plperl, le propriétaire d’une fonction spécialement conçue peut exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14671: Une confusion de type dans le cache de plans du module refint permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange de types dans le module refint de PostgreSQL permet au créateur d’un objet d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Le correctif a débuté comme un rapport de bug non identifié comme problème de sécurité, et apparaît dans le dépôt git sous le sujet « refint: Remove plan cache. », sans numéro de CVE. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14672: Une différence de réponse observable avec un scram_iterations différent du défaut permet de deviner l’existence d’un utilisateur

CVSS v3.1 Base Score: 5.3
Versions vulnérables : 16 - 18.
Une différence de réponse observable dans l’authentification SCRAM de PostgreSQL permet à un utilisateur non authentifié de tester l’existence d’un utilisateur en observant le nombre d’itérations SCRAM. Cela suppose que l’utilisateur sondé ait un scram_iterations différent de la valeur par défaut, car la comparaison d’authentification pour un utilisateur inexistant renvoie la valeur par défaut. Parmi les versions majeures 16, 17 et 18, les versions mineures antérieures à PostgreSQL 18.5, 17.11 et 16.15 sont concernées. Les versions antérieures à PostgreSQL 16 ne sont pas concernées.

CVE-2026-14673: Le module amcheck de PostgreSQL ne réinitialise pas un search_path non fiable

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14, 15, 16 et 18.
Un search_path non fiable dans le module amcheck permet à un utilisateur disposant du droit EXECUTE sur les fonctions d’amcheck d’exécuter des fonctions arbitraires avec les droits des propriétaires des index d’expression qui dépendent du search_path. Un attaquant peut exploiter cette faille en positionnant un search_path malveillant avant d’appeler la fonction d’amcheck. Les versions antérieures à PostgreSQL 18.5, 16.15, 15.19 et 14.24 sont concernées. PostgreSQL 17 n’est pas concerné.

CVE-2026-14676: Un dépassement de heap buffer dans pg_stat_statements permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 18.
Un dépassement de heap buffer dans pg_stat_statements permet à l’auteur d’une requête d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des requêtes spécialement conçues contenant des constantes de type array. Les versions antérieures à PostgreSQL 18.5 sont concernées. Les versions majeures antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-14677: pltcl et plperl en 32 bits sous-dimensionnent des allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un débordement d’entier dans les versions compilées en 32 bits de pltcl et plperl permet au créateur d’un objet de forcer le serveur à sous-dimensionner une allocation et à écrire hors limites, via des fonctions spécialement conçues. Cela peut conduire à l’exécution de code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. La CVE-2026-6473 avait corrigé des problèmes similaires. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14678: La fonction picksplit de pg_trgm lit au-delà de la limite d’un tampon

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une lecture hors limites dans la fonction picksplit des index pg_trgm lit au-delà de la fin d’un heap buffer. Cela peut permettre au mainteneur d’une table de déduire certaines valeurs mémoire, via les imprécisions que constituent les choix de fractionnement d’index. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14679: Un dépassement de stack buffer lors de la correspondance des arguments écrit 0x0 et 0x1 dans la mémoire du serveur

CVSS v3.1 Base Score: 8.2
Versions vulnérables : 14 - 18.
Un dépassement de stack buffer lors de la mise en correspondance des noms d’arguments permet au créateur d’un objet d’obtenir des effets indéterminés, via le nombre de paramètres OUT. L’attaque ne peut écrire que les octets 0x0 et 0x1 dans la mémoire du serveur. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14680: Mélange de type via les arguments de type « internal »

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange de types dans les arguments de type internal permet à n’importe quel utilisateur d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des appels à des fonctions utilisant ce type d’argument. Le type internal représente une famille de structures de données mutuellement incompatibles, et non destinées à être manipulées depuis SQL. Le système censé empêcher de tels appels de fonction avait des failles. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14681: Vérification incorrecte par PostgreSQL du chiffrement GSSAPI lorsqu’il est couplé à SSL

CVSS v3.1 Base Score: 4.2
Versions vulnérables : 17 - 18.
Une vérification incorrecte de l’intégrité des messages dans le support GSSAPI de PostgreSQL permet à un utilisateur de procéder à une négociation GSSAPI en dépit des règles du pg_hba.conf, en passant d’abord par une connexion TLS directe. Bien que le pg_hba.conf semble imposer GSSAPI, la connexion peut échanger des données par TLS uniquement. Si les réglages TLS sont plus permissifs que les réglages GSS, la connexion peut se poursuivre avec un niveau de protection moindre. Parmi les versions majeures 17 et 18, les versions mineures antérieures à PostgreSQL 18.5 et 17.11 sont concernées. Les versions antérieures à PostgreSQL 17 ne sont pas concernées.

CVE-2026-15741: La désérialisation d’expressions autorise une injection SQL via un argument d’EXTRACT

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Une faille d’injection SQL dans l’analyse (deparse) dans EXTRACT() permet au propriétaire d’un objet d’exécuter du code SQL arbitraire en tant que superutilisateur, via une définition d’objet hostile. La faille touche largement les consommateurs de cette reconstruction d’expressions, dont pg_dump, la commande \sf de psql et les usages similaires dans des outils tiers. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-15742: fuzzystrmatch écrit à des adresses arbitraires, à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un débordement d’entier dans le module fuzzystrmatch permet à un utilisateur de diriger des écritures vers une très large plage d’adresses, et donc d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des entrées extrêmes fournies aux fonctions levenshtein() ou levenshtein_less_equal(). Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-16238: Un mélange de types dans pg_restore_attribute_stats() permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 18.
Un mélange de types dans la fonction pg_restore_attribute_stats() permet au créateur d’un objet d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Il peut profiter d’une confusion entre valeurs de type range et multirange lors de la restauration des statistiques d’attribut. Les versions antérieures à PostgreSQL 18.5 sont concernées. Les versions majeures antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-16239: Une confusion de type lors d’un CLOSE + DECLARE de curseur permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange des types dans le cycle de vie des portal/curseurs permet à un utilisateur d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. L’exploitation passe par la recréation d’un curseur, ou d’un autre portal, avec des types différents. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-16241: Un dépassement négatif d’entier dans ECPG peut faire planter le client

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14 - 18.
Un dépassement négatif d’entier dans ECPG permet à un administrateur du serveur de base de données d’obtenir un déni de service temporaire du client ECPG, en envoyant une valeur bytea dépourvue du préfixe obligatoire. Le client écrase alors une très large zone mémoire avec des octets qui échappent à la connaissance et au contrôle de l’attaquant. Cela produit généralement un simple SIGSEGV, mais dans de rares cas, cela pourrait avoir un impact sur l’intégrité du client via cette écriture. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-18024: La fonction ascii() lit au-delà de la limite d’un tampon

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une lecture hors limites dans la fonction SQL ascii() permet à un utilisateur de divulguer jusqu’à 3 octets situés après la fin d’une allocation donnée, via une valeur texte spécialement conçue. Il s’agit de la même classe de bugs que celle corrigée par la CVE-2026-2006, mais avec un impact moindre. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-18408: La commande \unrestrict de psql permet au superutilisateur du serveur d’origine d’un pg_dump d’exécuter du code arbitraire dans le client psql

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
L’inclusion de données non fiables dans pg_dump permet à un superutilisateur malveillant du serveur d’origine d’injecter du code arbitraire, exécuté au moment de la restauration sous le compte système exécutant psql, via l’expansion des arguments de la méta-commande \restrict de psql. Le correctif de la CVE-2025-8714 avait introduit \restrict et \unrestrict pour bloquer cette attaque, mais \unrestrict suffisait à lui seul à la mener. Sont concernés pg_dump, pg_dumpall et pg_restore lorsqu’il est utilisé pour produire une sauvegarde au format plain. Un usage tiers de \restrict pourrait être affecté, mais aucun usage de ce type n’a été identifié. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-19385: Un dépassement de heap buffer dans pg_dump permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans pg_dump, lié à une trop longue liste de transformations de fonctions, permet à un créateur d’objet d’exécuter du code arbitraire en tant qu’utilisateur système exécutant pg_dump, via une liste de transformations malveillante. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

Correctifs et améliorations

Cette mise à jour corrige plus de 110 bugs reportés au cours des derniers mois.

Le problème suivant ne concerne que PostgreSQL 14, 15 et 16, mais nous le mettons en avant ici en raison de sa gravité :

  • Correction d’un auto-verrouillage (self-deadlock) pouvant survenir lors du rejeu de WAL générés par une version mineure antérieure. Cette régression, introduite dans la précédente série de versions mineures, pouvait bloquer une instance standby suivant une instance primaire dans une version mineure plus ancienne.

Les correctifs suivants concernent PostgreSQL 18. Beaucoup d’entre eux s’appliquent également aux autres versions supportées.

  • Correction de la construction parallélisée des index GIN afin que la valeur reltuples de la table soit correctement mise à jour dans pg_class. Auparavant, un worker parallèle pouvait remonter un nombre de lignes non initialisé, laissant reltuples à une valeur aberrante (dont Infinity ou NaN). Une telle valeur peut empêcher l’autovacuum et l’autoanalyze de traiter la table, et la situation ne se corrige pas d’elle-même. Si vous avez des tables avec des index GIN, vérifiez que leur reltuples est cohérent après la mise à jour. Voir la section « Mettre à jour ».
  • Plusieurs correctifs pour les index btree_gist, dont la gestion des NaN pour les types float4/float8, qui pouvait donner des résultats erronés sur les colonnes contenant des NaN et le tri correct des valeurs bit/bit varying lors de la construction de l’index. Une réindexation sur les colonnes de type float ou bit peut être nécessaire après la mise à jour. Voir la section « Mettre à jour ».
  • Correction d’un débordement d’entier dans les comparaisons ltree. Les valeurs ltree comportant plus de 14 653 labels environ pouvaient être comparées incorrectement, avec pour conséquence un index B-tree corrompu. Une réindexation des index affectés peut être nécessaire après la mise à jour. Voir la section « Mettre à jour ».
  • Correction du partition pruning pour les tables partitionnées par RANGE, afin que la partition DEFAULT ne soit plus ignorée alors qu’elle doit être parcourue. Auparavant, des lignes pouvaient manquer dans les résultats de requête.
  • Plusieurs correctifs pour les tables partitionnées avec des tables distantes (foreign-table) comme partition : lorsque l’élagage des partitions à l’exécution déterminait que certaines partitions n’avaient pas à être parcourues, les requêtes en cours vers les serveurs distants n’étaient pas toujours gérées correctement, provoquant des échecs.
  • Plusieurs correctifs sur RETURNING avec OLD et NEW.
  • Amélioration des performances des hash join lorsqu’il y a plusieurs clés de jointure et de nombreuses valeurs NULL.
  • Plusieurs correctifs du planificateur qui pouvaient produire des résultats erronés, notamment pour les tests valeur IN (tableau) où le tableau peut être vide, et pour les fonctions de fenêtrage COUNT() avec une clause EXCLUDE ou dépourvues d’ORDER BY.
  • Ajout des vérifications manquantes sur la « hachabilité » des comparaisons d’égalité pour les types conteneurs (array, composite types et ranges). Sans ces vérifications, le planificateur pouvait choisir un plan basé sur le hachage qui échouait ensuite à l’exécution avec l’erreur « could not identify a hash function ».
  • Correction de l’attachement de partitions d’index qui sont des contraintes d’exclusion, ce qui corrige aussi la sauvegarde et la restauration des contraintes d’exclusion partitionnées.
  • Correction de REINDEX CONCURRENTLY sur un index supportant une contrainte d’unicité différée, qui pouvait provoquer de fausses violations de contrainte.
  • Rétablissement d’une optimisation de parcours d’index qui convertit un motif LIKE ou une expression rationnelle à correspondance exacte en une condition d’égalité sur l’index, lorsque les collations de l’index et de l’expression diffèrent.
  • Plusieurs correctifs sur jsonpath : les opérateurs @? et @@ lèvent désormais correctement une erreur pour une variable non définie dans l’expression du chemin. Auparavant, ces opérateurs ne pouvant pas fournir de valeur de variable, une variable non définie était traitée comme un null JSON au lieu de produire une erreur, ce qui pouvait aussi entraîner une consommation mémoire non bornée.
  • Garantie du blocage de l’accès aux tables temporaires des autres sessions, qui pouvait conduire à des résultats silencieusement incorrects.
  • Correction des erreurs "no empty local buffer available" lors de l’accès à des tables temporaires, un effective_io_concurrency élevé pouvant permettre à un seul flux de lecture de consommer tous les buffers locaux.
  • L’autovacuum ne traite plus les bases dans le mauvais ordre, à savoir la plus faible priorité d’abord au lieu de la plus forte.
  • Rétablissement du mode failsafe de VACUUM contre le wraparound, afin qu’il utilise l’intégralité du pool de shared buffers comme prévu, ce qui ralentissait les vacuums d’urgence.
  • Correction d’un décodage possiblement incorrect des entrées d’index lors des index-only scans GiST et SP-GiST, qui pouvait renvoyer des données corrompues.
  • Correction d’une race condition dans la détection de conflits en niveau d’isolation SERIALIZABLE. Un conflit pouvait être manqué lors de l’examen d’un index B-tree initialement vide, laissant des transactions en conflit être validées, rompant au passage la sérialisabilité.
  • Correction de la journalisation dans les WAL des opérations qui effacent des bits dans les visibility maps des tables. Cela pouvait produire des sauvegardes incrémentales incorrectes ou laisser des écritures de pages partielles non corrigées.
  • Correction du décodage logique des transactions préparées vides. Une transaction préparée sans changement décodable pouvait envoyer un COMMIT PREPARED ou un ROLLBACK PREPARED au plugin de sortie sans PREPARE préalable, ce qui casse la réplication pour l’abonné natif.
  • Plusieurs correctifs sur libpq, dont la garantie que tous les octets en attente dans le tampon de déchiffrement SSL ou GSS sont bien consommés lors de la lecture des données, évitant qu’un client n’attende des données déjà arrivées.
  • Correction de pg_createsubscriber pour qu’il nettoie les objets laissés sur le publieur après un échec, y compris un slot de réplication.
  • Correction de pg_restore avec --statistics ou --statistics-only pour que, combiné à d’autres options de restauration sélective comme --schema, il restaure bien les objets attendus, conformément au comportement de pg_dump.

Cette mise à jour intègre également les données de fuseaux horaires tzdata 2026c : l’Alberta (America/Edmonton) passera à UTC-06 toute l’année (soit un horaire d’été permanent) à partir de novembre 2026, avec l’hypothèse que l’abréviation de fuseau sera CST à partir de cette date (cela pourrait changer). Le Maroc (Africa/Casablanca) passera quant à lui à UTC+00 permanent, sans changement d’heure, le 20 septembre 2026.

Mettre à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Pour appliquer la mise à jour, 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. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Si vous avez des tables comportant des index GIN, nous vous recommandons de vérifier leur valeur reltuples après la mise à jour. Un bug dans la construction parallélisée des index GIN a pu laisser reltuples à une valeur aberrante (dont Infinity ou NaN) qui empêche définitivement l’autovacuum et l’autoanalyze de traiter la table. La requête suivante liste les tables possédant un index GIN, avec leur reltuples courant :

SELECT DISTINCT t.oid::regclass, t.reltuples
  FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
 WHERE t.relhasindex AND ic.relam = 2742;

Pour toute table dont la valeur reltuples semble incorrecte, exécutez un ANALYZE dessus (ou créez un autre index) pour réinitialiser la valeur.

Si vous utilisez btree_gist, vous devez réindexer les index btree_gist sur les colonnes float4 ou float8 susceptibles de contenir des valeurs NaN, ainsi que les index btree_gist sur des colonnes bit ou bit varying, par exemple :

REINDEX INDEX nom_de_votre_index;

Si vous utilisez ltree et que vous avez des index btree sur des valeurs ltree comportant un très grand nombre de labels (plus de 14 653 environ), vous devez réindexer ces index, car ils peuvent être corrompus, par exemple :

REINDEX INDEX nom_de_votre_index;

Les utilisateurs ayant sauté une version mineure ou plus peuvent avoir besoin de réaliser d’autres opérations post-mise à jour. Voir les Notes de version pour les détails.

À propos de la bêta de PostgreSQL 19

Cette version marque la troisième beta de PostgreSQL 19. Dans l’esprit de la communauté open source PostgreSQL, nous vous encourageons vivement à tester les nouvelles fonctionnalités de PostgreSQL 19 sur vos systèmes pour aider à éliminer bugs et autres problèmes. Nous ne conseillons pas d’exécuter PostgreSQL 19 Beta 3 en production, mais plutôt de trouver des moyens de faire tourner vos charges applicatives habituelles sur cette version bêta. Pour en savoir plus, voir le processus de test des versions beta.

Parmi les changements depuis la bêta 2 :

  • Retrait de GROUP BY ALL.
  • Plusieurs correctifs sur la nouvelle syntaxe FOR PORTION OF des tables temporelles.
  • Plusieurs correctifs sur la nouvelle fonctionnalité de synchronisation des séquences en réplication logique, dont une race condition impliquant REFRESH SEQUENCES.
  • Correction d’une erreur « unexpected logical decoding status change » pouvant survenir lorsque le décodage logique est activé de manière concurrente.
  • Correction de problèmes liés aux changements de propriétaire des abonnements.
  • Correction de résultats de requête erronés avec postgres_fdw, lors d’un push down d’une comparaison de tableau comme champ = ANY($1) impliquant une conversion de type implicite.
  • Correction d’un plantage lors des vérifications de clé étrangère impliquant une contrainte UNIQUE acceptant les valeurs nulles.
  • Correction du parsing par pg_plan_advice des tirets bas (underscore) dans les littéraux numériques.
  • Correction d’une clause FORMAT manquante lors de la reconstruction textuelle de JSON_ARRAY(query).

Pour la liste complète des nouvelles fonctionnalités et des changements, voir les notes de version] :

https://www.postgresql.org/docs/19/release-19.html

Tests des bugs et de la compatibilité

La stabilité de chaque version de PostgreSQL dépend grandement de vous, la communauté, pour tester la version à venir avec vos charges applicatives et vos outils de test, afin de trouver les bugs et les régressions avant la disponibilité publique de PostgreSQL 19. S’agissant d’une bêta, des changements mineurs de comportement de la base de données, de détails de fonctionnalités et d’API restent possibles. Vos retours et vos tests aideront à déterminer les derniers ajustements des nouvelles fonctionnalités, alors n’hésitez pas à tester rapidement. La qualité des tests réalisés par les utilisateurs détermine quand la version finale pourra être publiée.

Une liste des sujets en cours est disponible publiquement sur le wiki PostgreSQL. Vous pouvez signaler des bugs via ce formulaire sur le site de PostgreSQL :

https://www.postgresql.org/account/submitbug/

Liens

Si vous avez des corrections ou des suggestions concernant cette annonce de version, merci de les envoyer à la liste de diffusion publique pgsql-www@lists.postgresql.org (mailing list).


DALIBO

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