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_gistltree
Pour la liste complète, voir les Notes de version.

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
reltuplesde la table soit correctement mise à jour danspg_class. Auparavant, un worker parallèle pouvait remonter un nombre de lignes non initialisé, laissantreltuplesà une valeur aberrante (dontInfinityouNaN). 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 leurreltuplesest cohérent après la mise à jour. Voir la section « Mettre à jour ». - Plusieurs correctifs pour les index
btree_gist, dont la gestion desNaNpour les typesfloat4/float8, qui pouvait donner des résultats erronés sur les colonnes contenant desNaNet le tri correct des valeursbit/bit varyinglors de la construction de l’index. Une réindexation sur les colonnes de typefloatoubitpeut ê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 valeursltreecomportant 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 partitionDEFAULTne 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
RETURNINGavecOLDetNEW. - 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êtrageCOUNT()avec une clauseEXCLUDEou 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 CONCURRENTLYsur 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
LIKEou 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 unnullJSON 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, uneffective_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
VACUUMcontre 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 PREPAREDou unROLLBACK PREPAREDau plugin de sortie sansPREPAREpré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_createsubscriberpour qu’il nettoie les objets laissés sur le publieur après un échec, y compris un slot de réplication. - Correction de
pg_restoreavec--statisticsou--statistics-onlypour que, combiné à d’autres options de restauration sélective comme--schema, il restaure bien les objets attendus, conformément au comportement depg_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 OFdes 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 commechamp = ANY($1)impliquant une conversion de type implicite. - Correction d’un plantage lors des vérifications de clé étrangère impliquant
une contrainte
UNIQUEacceptant les valeurs nulles. - Correction du parsing par
pg_plan_advicedes tirets bas (underscore) dans les littéraux numériques. - Correction d’une clause
FORMATmanquante lors de la reconstruction textuelle deJSON_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).
- PostgreSQL (481) ,
- release (100) ,
- mineure (41) ,
- sécurité (71) ,
- 19 (1) ,
- 18 (10) ,
- 17 (17) ,
- 16 (22) ,
- 15 (24) ,
- 14 (34) ,
- update (56)