Le blog Dalibo

Sortie de PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23

Fri, 15 May 2026 00:00:00 -0500

Lyon, le 15 mai 2026

Le PostgreSQL Global Development Group a publié le 14 mai une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.4, 17.10, 16.14, 15.18, 14.23. Cette mise à jour corrige 11 vulnérabilités de sécurité et une soixantaine de bugs.

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 la migration vers une version plus récente et supportée. Voir la politique de versionnement pour plus de détails.

Vulnérabilités de sécurité

CVE-2026-6472: La commande CREATE TYPE de PostgreSQL ne vérifie pas le droit CREATE de sur tous les schemas

CVSS v3.1 Base Score: 5.4
Versions vulnérables : 14 - 18.
Une faille d’autorisation dans la commande CREATE TYPE de PostgreSQL permet au créateur d’un objet de détourner d’autres requêtes qui utilisent search_path pour rechercher des types définis par l’utilisateur, y compris les types définis par des extensions. En d’autres termes, la victime exécutera des fonctions SQL arbitraires choisies par l’attaquant. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6473: PostgreSQL sous-dimensionne les allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Le débordement d’entier, dans plusieurs fonctionnalitées de PostgreSQL, autorise une application à forcer le serveur à sous-dimensionner une allocation et à écrire hors limites. Cela entraîne une erreur de segmentation. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6474: La fonction PostgreSQL timeofday() peut divulguer des parties de la mémoire du serveur

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une chaîne de caractères spécifique utilisée dans la fonction timeofday() de PostgreSQL permet à un attaquant d’extraire des portions de la mémoire du serveur, via des fuseaux horaires spécialement conçus. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6475: Les commandes pg_basebackup et pg_rewind de PostgreSQL peuvent écraser des fichiers sans lien avec le choix du superutilisateur

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Le suivi des liens symboliques dans le format brut de pg_basebackup et dans pg_rewind permet à un superutilisateur d’origine de réécrire des fichiers locaux, par exemple /var/lib/postgres/.bashrc, qui détournent le compte du système d’exploitation. Le fait est que le démarrage du serveur après ces commandes implique une confiance implicite envers le superutilisateur d’origine, en raison de fonctionnalités telles que shared_preload_libraries. Par conséquent, l’attaque n’a de conséquences pratiques que si des actions sont faites entre l’exécution de ces commandes et le démarrage du serveur, comme par exemple le déplacement des fichiers vers une autre machine virtuelle ou la création d’un instantané de la machine virtuelle. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6476: La fonction pg_createsubscriber de PostgreSQL permet une injection SQL via le nom de l’abonnement

CVSS v3.1 Base Score: 7.2
Versions vulnérables : 17 - 18.
Une faille d’injection SQL dans la fonction pg_createsubscriber de PostgreSQL permet à un attaquant disposant des droits pg_create_subscription d’exécuter du code SQL arbitraire en tant que superutilisateur. L’attaque se produit lors de la prochaine exécution de pg_createsubscriber. Parmi les versions majeures 17 et 18, les versions mineures antérieures à PostgreSQL 18.4 et 17.10 sont concernées. Les versions antérieures à PostgreSQL 17 ne sont pas concernées.

CVE-2026-6477: Les fonctions lo_* de la bibliothèque libpq de PostgreSQL permettent au superutilisateur du serveur de réécrire la mémoire de la pile du client

CVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
L’utilisation de la fonction intrinsèquement dangereuse comme PQfn(..., result_is_int=0, ...) dans les fonctions lo_export(), lo_read(), lo_lseek64(), and lo_tell64() de la libpq autorise un superutilisateur de réécrire la pile mémoire d’un client. C’est notamment le cas pour pg_dump et psql qui utilisent lo_read(). Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6478: PostgreSQL divulgue des mots de passe hachés en MD5

CVSS v3.1 Base Score: 6.5
Versions vulnérables : 14 - 18.
Un canal de synchronisation caché dans la comparaison des mots de passe hachés MD5 dans l’authentification PostgreSQL permet à un attaquant de récupérer suffisament d’informations d’utilisateur pour s’authentifier. Cela n’affecte pas les mots de passe hachés en scram-sha-256, qui sont la valeur par défaut dans toutes les versions supportées. Cependant, les bases de données en version 13 existantes peuvent contenir des mots de passe hachés en MD5. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6479: L’initialisation SSL/GSS de PostgreSQL provoque un déni de service, via une récursion non contrôlée.

CVSS v3.1 Base Score: 7.5
Versions vulnérables : 14 - 18.
Une récursion incontrôlée dans la négociation SSL et GSS de PostgreSQL permet à un attaquant capable de se connecter à un socket AF_UNIX de PostgreSQL, d’obtenir un déni de service. Si SSL et GSS sont désactivés, un attaquant peut réaliser la même opération en accédant à un socket TCP de PostgreSQL. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6575: La fonction pg_restore_attribute_stats de PostgreSQL accepte des valeurs qui entraînent une lecture au-delà de la fin du tableau de statistiques lors de la planification de la requête.

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 18.
Une vulnérabilité de lecture du tampon dans la fonction pg_restore_attribute_stats() de PostgreSQL accepte des valeurs de tableau de longueur non adéquat, ce qui provoque une lecture au-delà de la fin d’un tableau lors de la planification de la requête. Ceci permet à un responsable de table de déduire des valeurs en mémoire au-delà de cette fin de tableau. Ce problème affecte les versions majeures antérieures à PostgreSQL 18 et 18.4. Les versions antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-6637: Le module PostgreSQL refint permet le dépassement de tampon de pile et l’injection SQL.

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de tampon de la pile dans le module refint de PostgreSQL permet à un utilisateur de base de données non privilégié d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Une autre attaque est possible si l’application déclare une colonne utilisateur comme clé primaire en cascade. Une injection SQL est possible en mettant à jour la valeur de la clé primaire. Le code SQL est exécuté en tant qu’utilisateur de la base de données effectuant la mise à jour de la clé primaire. Les versions de PostgreSQL antérieures à 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6638: PostgreSQL REFRESH PUBLICATION autorise l’injection SQL via le nom de la table.

CVSS v3.1 Base Score: 3.7
Versions vulnérables : 16 - 18.
Une injection SQL dans la réplication logique de PostgreSQL (ALTER SUBSCRIPTION ... REFRESH PUBLICATION) permet au créateur d’une table abonnée d’exécuter du code SQL arbitraire avec les identifiants de publication de l’abonnement. L’attaque prend effet lors du prochain appel à REFRESH PUBLICATION. Les versions majeures 16, 17 et 18, ainsi que les versions mineures antérieures à PostgreSQL 18.4, 17.10 et 16.14, sont concernées. Les versions antérieures à PostgreSQL 16 ne sont pas affectées.

Correctifs et améliorations

Correction d’un problème pouvant entraîner des résultats erronés lors de l’utilisation d’une collation non déterministe sur un index unique.
Auparavant, une clé étrangère définie comme DEFERRABLE INITIALLY DEFERRED se comportait comme si elle était NOT DEFERRABLE après avoir été mise en état NOT ENFORCED, puis revenue à l’état ENFORCED. C’est maintenant corrigé. Si vous avez une clé étrangère présentant ce problème, vous pouvez le résoudre après avoir installé cette mise à jour en la positionnant comme NOT ENFORCED puis ENFORCED.
Amélioration du planificateur lors du nettoyage de partitions.
Correctif sur les self-join pour mieux gérer les clauses qui ne portent que sur des colonnes de type booléen.
Plusieurs corrections concernent les colonnes générées virtuellement, notamment pour garantir que INSERT ... ON CONFLICT fonctionne lorsque EXCLUDED fait référence à une colonne générée virtuellement.
Un échec de sérialisation est signalé lorsque MERGE rencontre une ligne mis à jour simultanément avec les modes d’isolation « repeatable » ou « serializable ».
Correction de CREATE TABLE ... LIKE ... INCLUDING STATISTICS pour les cas où la table source comportait une ou plusieurs colonnes supprimées.
Correction de WITHOUT OVERLAPS pour autoriser l’utilisation de domaines.
Interdiction de faire d’un type composite un membre de lui-même via un multirange.
Correction de résultats parfois incorrects lorsque array_agg(anyarray) s’exécute en parallèle.
Le bloat n’est plus conservé lors d’une restauration à partir d’une sauvegarde incrémentale.
La promotion d’une instance standby n’est plus bloquée par un processus de synchronisation des slots de réplication logique.
La colonne pid de la vue système pg_aios affiche NULL au lieu de 0 lorsqu’une entrée n’a pas de processus associé.
Correction des cas où pg_stat_replication affiche un lag NULL même lorsque la réplication est active.
L’affichage des variables d’alias JOIN utilisées dans GROUP BY est maintenant correct.
Si le processus de démarrage échoue, les autres processus enfants sont correctement arrêtés avant de stopper le postmaster.
Correction d’une race condition qui pouvait entraîner une instance stanby, suivant une instance primaire dans une version mineure antérieure, à entrer dans une boucle infinie de plantage et de redémarrage.
Empêche l’attente infine lors de l’arrêt d’un processus walsender lorsque la réplication logique publie activement des données.
Les modifications apportées aux free space map des tables sont conservées pendant un recovery. Cela pourrait améliorer les performances d’une instance standby après sa promotion.
Correction de divers bugs dans le code de décompression des sauvegardes utilisé dans pg_basebackup et pg_verifybackup.
Garantie que pg_dumpall n’oublie pas de GRANT sur des rôles qui auraient été donnés par un ROLE dont l’OID serait manquant.. Un message d’avertissement est affiché sur la source du dump est PostgreSQL 16 ou une version ultérieure.
Correction de pg_upgrade pour qu’il utilise la bonne version du protocole lors de la connexion à d’anciens serveurs sources.
Correction de la sortie dans pg_overexplain lors de l’utilisation de l’option RANGE_TABLE.
Correction d’un bug dans postgres_fdw causé par le nettoyage prématuré d’une connexion ayant échoué.

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.

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.

Liens

Manuels Dalibo : leur dernière mise à jour intègre PostgreSQL 18

Fri, 15 May 2026 00:00:00 -0500

Saint-Étienne, le 15 mai 2026

Voici les manuels Dalibo dans leur dernière version, qui intègre les nouveautés de PostgreSQL 18. Toujours en libre accès sous format PDF, ePub, html et slides !

Rappels utiles

Revue des cours, nouveaux TP et quiz, correctifs… La mise à jour des manuels est assurée nos DBA, par ailleurs formateurs et consultants.

Découvrez le sommaire des formations Dalibo, le détail des différents modules et les liens vers les slides ici.

Si vous notez des éléments qui demandent à être clarifiés, précisés, corrigés, vous pouvez nous écrire à formation@dalibo.com.

Les manuels sont publiés sous la licence CC BY-NC-SA qui autorise l’utilisation non commerciale, le partage dans les mêmes conditions et la modification, à condition de créditer Dalibo.

Les manuels

IMPORTANT : leur dernière version intègre les nouveautés de PostgreSQL 18.

Administration

DBA1 - Administration PostgreSQL : PDF, ePub, html
DBA2 - Administration PostgreSQL Avancée : PDF, ePub, html
DBA3 - Sauvegarde et Réplication avec PostgreSQL : PDF, ePub, html
HAPAT - Haute disponibilité avec PostgreSQL : PDF, ePub, html

Développement

DEVPG - Développer avec SQL : PDF, ePub, html

Performances

PERF1 - PostgreSQL Performances : PDF, ePub, html
PERF2 - Indexation et SQL Avancés : PDF, ePub, html

Transition vers PostgreSQL

DBAADM - Administration PostgreSQL pour DBA expérientés : PDF, ePub, html

Le privilège des stagiaires

Ces manuels ne sont pas commercialisés. Cependant, en vous inscrivant à une formation Dalibo, vous recevrez un code pour commander gratuitement l’impression et la livraison à domicile de deux manuels de votre choix.

Nous rappelons d’ailleurs que nos DBA donnent ces formations en intra ou inter-entreprises, en présentiel dans nos locaux parisiens, ou à distance.

En attendant, bonne lecture à vous !

Des questions, des remarques ?

Écrivez-nous à formation@dalibo.com.

Plongez dans le monde de CloudNativePG #11 - Exécuter des ordres SQL après la création d'un Cluster

Wed, 11 Mar 2026 00:00:00 -0500

Lyon, le 11 mars 2026

CloudNativePG ou comment embarquer un éléphant sur un porte-conteneurs !

Jusqu’à présent, nous avons abordé différents sujets liés à l’administration d’instances PostgreSQL avec CloudNativePG. On nous a récemment posé une question concernant les possibilités pour exécuter des requêtes dès la création d’un Cluster. Regardons ce que propose l’opérateur.

Le besoin

Le besoin rencontré est le suivant : les Clusters vont tous être créés sur le même modèle (RAM, CPU, etc) et seront utilisés par une application pour laquelle nous possédons déjà le modèle de données.

Nous voulons donc créer toute la structure d’une nouvelle base dès la création du Cluster. Une fois notre YAML appliqué, l’instance et la base de données seront directement utilisables par nos développeurs qui pourront connecter l’application dessus.

Les trois sections postInit

L’opérateur donne la possibilité d’exécuter des ordres SQL lors de la phase de bootstrap d’un Cluster via les sections postInitXXX. Elles sont localisées dans la section initdb.

Il en existe trois :

pour la base postgres : la section postInit;
pour la base template1 : la section postInitTemplate;
pour la base app : la section postInitApplication.

Les ordres SQL, indiqués dans l’une ou l’autre des sections, s’exécuteront dans la base correspondante dès la fin de la création de l’instance.

Ces ordres là sont lancés par le rôle postgres, qui est SUPERUSER. Attention donc aux requêtes que vous lancerez et à qui vous laisserez la possibilité d’utiliser ces sections.

Exemple d’un ordre SQL

Reprenons notre exemple où le modèle de données doit être créé dans une base de données, disons mybase qui sera utilisée par la future application. Prenons le cas simple où nous souhaitons créer une table avec la définition suivante :

CREATE TABLE employes (id serial, nom text, paye numeric(8,2));

Cet ordre doit être rajouté à la section spec.bootstrap.initdb.postInitApplicationSQL pour que l’ordre en question soit exécuté dans la base de données applicative mybase.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-sql
spec:
  instances: 2
  storage:
    size: 1Gi
  bootstrap:
    initdb:
      database: mybase
      owner: mybase
      postInitApplicationSQL: 
      -  CREATE TABLE employes (id serial, nom text, paye numeric(8,2)) ;

Le Cluster peut-être créé avec la commande kubectl create ou kubectl apply. On vous laisse créer cette ressource et vérifier que la table existe bien 😏.

Pour des raisons d’organisation et de lisibilité il est pertinent de séparer correctement chaque action SQL. Pour une dizaine d’ordres SQL, cette solution est tout à fait viable, mais au-delà, cela deviendrait très compliqué à utiliser et à maintenir.

Une autre solution est proposée par l’opérateur avec l’utilisation de ressources ConfigMap ou Secret.

Exemple via ConfigMap

Pour le test, nous n’utiliserons que des ConfigMap. Nous vous laissons le loisir de tester les étapes qui suivent avec un objet Secret.

L’un des intérêts d’un ConfigMap est de regrouper des requêtes SQL et de les appeler au besoin lors des créations de Cluster. Ce sont des ressources qui peuvent être réutilisées.

Un autre avantage est de pouvoir mettre un grand nombre d’ordres SQL sans que cela ne rende la définition du Cluster illisible. Voici les quelques étapes à suivre pour mettre en place cette méthode.

Tout d’abord, écrire la définition du ConfigMap. La section data contient un champ sql qui, vous le verrez, sera utilisé plus tard lors de la création du Cluster. Le mot sql a été choisi pour qu’il corresponde sémantiquement au contenu, mais vous pouvez l’appeler comme vous voulez.

$ cat cm.yaml

apiVersion: v1 
kind: ConfigMap
metadata: 
  name: my-configmap
data:
  sql: | 
    CREATE TABLE liste (i integer) ; 
    INSERT INTO liste SELECT i from generate_series(1,100) as i ;

Créer cette ressource dans le cluster Kubernetes.

kubectl apply -f cm.yaml

Penchons-nous maintenant sur la création de la ressource Cluster afin d’utiliser ce ConfigMap.

Ce qui nous intéresse le plus est la partie postInitApplicationSQLRefs. Vous l’aurez remarqué, il s’agit ici d’une liste de références à des objets, un ou des ConfigMap donc, et non plus une liste d’ordres SQL. Le nom de la section change également, avec l’ajout du suffixe Refs. Vous l’aurez compris il existe là aussi trois nouveaux paramètres correspondant aux trois sections précédentes

postInitSQLRefs ;
postInitTemplateSQLRefs ;
postInitApplicationSQLRefs.

Reprenons l’exemple de notre Cluster :

...
  bootstrap:
    initdb:
      database: mybase
      owner: mybase
      postInitApplicationSQLRefs:
        configMapRefs:
        - name: my-configmap
          key: sql

Il est nécessaire de cibler le ConfigMap avec l’attribut name et la clé présente dans celui-ci, en l’occurrence : sql.

Créons ce Cluster et vérifions que la table et les données sont bien présentes.

kubectl cnpg psql cluster-cm -- -d mybase -c "select count(*) from liste"
 count 
-------
   100
(1 row)

Bien évidement, dans votre cas, le contenu de la ConfigMap sera bien plus conséquent.

Et si une erreur survient ?

L’erreur est humaine. Un administrateur aurait tendance à dire que PEBKAC … bref, regardons ce qu’il se passe si une erreur survient lors de l’exécution des ordres SQL.

Modifions une requête SQL (suppression de INTO) de notre ConfigMap et appliquons cette modification. Vous voyez au passage, qu’il n’y a pas de vérification du contenu d’un ConfigMap.

apiVersion: v1 
kind: ConfigMap
metadata: 
  name: my-configmap
data:
  sql: | 
    CREATE TABLE configmaps (i integer) ; 
    INSERT configmaps SELECT i from generate_series(1,100) as i ; 

Pour le test, il faut détruire et recréer le Cluster existant. Et oui, rappelez-vous que les opérations ne sont exécutées que lors du bootstrap, c’est à dire lors de la création du Cluster.

Une fois que ceci est fait, vous devriez voir, en lançant la commande kubectl get pod, un certain nombre de Pods avec le statut Error. L’opérateur essaye plusieurs fois de créer les Pods initdb.

kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
cluster-cm-1-initdb-k8qrx   0/1     Error     0          11m
cluster-cm-1-initdb-ksb9l   0/1     Error     0          13m
cluster-cm-1-initdb-p4t4p   0/1     Error     0          8m22s
cluster-cm-1-initdb-sdkmn   0/1     Error     0          13m
cluster-cm-1-initdb-tb87p   0/1     Error     0          2m58s
cluster-cm-1-initdb-wvn7h   0/1     Error     0          12m
cluster-cm-1-initdb-zqvd2   0/1     Error     0          13m
cluster-sql-1               1/1     Running   0          33m
cluster-sql-2               1/1     Running   0          32m

Il y a vraisemblablement une erreur. Regardons maintenant dans les traces du Pod, quelle en est la cause. Il est possible de cibler un conteneur spécifique avec l’option -c de la commande kubectl logs. Utilisons là pour cibler le conteneur initdb.

kubectl logs cluster-cm-1-initdb-zqvd2 -c initdb | jq

...

{
  "level": "info",
  "ts": "2026-03-09T09:30:09.800909636Z",
  "logger": "pg_ctl",
  "msg": "server stopped",
  "pipe": "stdout",
  "logging_pod": "cluster-cm-1-initdb"
}

L’instance PostgreSQL est arrêtée par l’opérateur. Pourquoi ?

{
  "level": "error",
  "ts": "2026-03-09T09:30:09.801691453Z",
  "msg": "Error while bootstrapping data directory",
  "logging_pod": "cluster-cm-1-initdb",
  "error": "while configuring new instance: could not execute post init application SQL refs: could not execute queries: ERROR: syntax error at or near \"liste\" (SQLSTATE 42601)",
  "stacktrace": "github.com/cloudnative-pg/machinery/...
  ...
}

L’ordre SQL renvoyant une erreur, l’opérateur le capte et arrête le processus initdb du Pod. Le cluster reste dans l’état Setting up Primary :

kubectl get cluster
NAME          AGE   INSTANCES   READY   STATUS                     PRIMARY
cluster-cm    15m   1                   Setting up primary     

Si le ConfigMap est corrigé assez rapidement, la boucle de réconciliation de CloudNativePG entrant en jeu, lors de la nouvelle tentative de création d’un Pod initdb, la ConfigMap est relue et la création du Cluster se fait sans encombre.

kubectl get pod

NAME                        READY   STATUS      RESTARTS   AGE
cluster-cm-1                1/1     Running     0          27s
cluster-cm-1-initdb-5z9d5   0/1     Error       0          58s
cluster-cm-1-initdb-6kb9n   0/1     Error       0          77s
cluster-cm-1-initdb-cxmkh   0/1     Completed   0          34s

Un Podd’initdb finit par être Completed et le Pod de l’instance cluster-cm-1 est créé.

Conclusion

Nous venons de voir comment demander à l’opérateur d’exécuter un certain nombre d’ordres SQL pour nous.

Vous avez deux possibilités, soit en indiquant des ordres SQL directement, soit en faisant référence à une ressource ConfigMap ou Secret. Cette dernière est d’autant plus pratique qu’elle vous permet de réutiliser des ConfigMap pour la création de vos Clusters.

Grâce à cette fonctionnalité de l’opérateur, vous n’avez plus besoin d’utiliser un autre outil pour déclencher la création de schémas, de tables ou d’autres ressources dans vos bases de données.

Des questions, des commentaires ? Écrivez-nous !

Nouveau workshop dédié à CloudNativePG™

Fri, 06 Mar 2026 00:00:00 -0600

Saint-Étienne, le 6 mars 2026

Dalibo vous propose un tout nouveau workshop, testé l’année dernière : celui dédié à l’opérateur CloudNativePG ! Il aura lieu le 8 avril à Paris.

Découvrir CloudNativePG

Initialement développé par Enterprise DB, CloudNativePG est désormais l’un des projets communautaires de la Fondation Linux.

Le but de ce workshop est de présenter cet opérateur, ce qu’il permet de faire, ses particularités… voici un aperçu des sujets qui seront abordés lors de cette journée de travail et d’échanges :

Installation
Montées de version
Custom Resource Definitions
Gestion des images
Gestion des traces

Streaming Replication / Log Shipping
Plugin Barman Cloud
PITR
Rolling Update
Etc.

Les inscriptions sont ouvertes pour le 8 avril 2026. Attention, il y a peu de places : premier arrivé, premier servi !

Liens utiles

documentation officielle
Premier aperçu (article)
conférence « CloudNativePG, ou comment embarquer un éléphant sur Kubernetes », ci-dessous :

Rappel général

Chaque workshop se déroule en présentiel, sur une journée, dans nos locaux parisiens.

Au programme : des démos, travaux pratiques et sessions de questions-réponses afin de vous familiariser avec le fonctionnement des logiciels.

L’inscription est gratuite, dans la limite d’une personne par organisation. Le coût du déjeuner est cependant pris en charge par les employeurs.

Pour toute question et réservation, écrivez-nous à workshop@dalibo.com. Un email de confirmation vous sera envoyé.

Des questions, des commentaires ? Écrivez-nous !

Sortie de PostgreSQL 18.3, 17.9, 16.13, 15.17 et 14.22

Thu, 26 Feb 2026 00:00:00 -0600

Strasbourg, le 26 février 2026

Le PostgreSQL Global Development Group a publié le 26 février une mise à jour mineure pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.3, 17.9, 16.1, 15.17 et 14.22.

Il s’agit d’une mise à jour hors cycle corrigeant plusieurs régressions signalées après la mise à jour précédente. Pour la liste complète, voir les Notes de version.

Voici notre traduction.

Correctifs et améliorations

Cette mise à jour corrige plusieurs bugs rapportés depuis la mise à jour précédente. Les problèmes ci-dessous concernent PostgreSQL 18. Certains peuvent également affecter d’autres versions supportées de PostgreSQL.

Correction d’un problème où un serveur standby s’arrêtait et renvoyait une erreur “could not access status of transaction”.
Correction d’une erreur où la fonction substring() levait une erreur “invalid byte sequence for encoding” sur des valeurs textuelles non-ASCII quand la source était une colonne de base de données. Cela était la conséquence d’un changement pour corriger la CVE-2026-2006.
Correction de la fonction strict_word_similarity dans pg_trgm, qui pouvait entraîner des résultats incorrects ou des plantages. Cela était dû à un oubli dans la correction de CVE-2026-2007.
Correction de la volatilité des fonctions json_strip_nulls() et jsonb_strip_nulls(), redevenues immutables comme dans les versions précédentes, permettant leur utilisation dans les index. Si vous avez précédemment mis à jour vers PostgreSQL 18.0 à 18.2, consultez les étapes supplémentaires dans la section « Mettre à jour ».
Correction de tests NOT NULL dans les sous-requêtes LATERAL UNION ALL, pouvant produire des résultats erronés.
Éviter que les contraintes NOT NULL ne génèrent des noms en conflit avec les contraintes définies par l’utilisateur.
Correction de pg_stat_get_backend_wait_event() et pg_stat_get_backend_wait_event_type() pour afficher les valeurs des processus auxiliaires, comme dans pg_stat_activity.
Correction du transtypage d’une variable de type composite vers un type domaine en retour d’une fonction PL/pgSQL.
Correction de la fonction d’entrée binaire de hstore pour éviter des plantages lors de l’entrée de clés dupliquées.

Mettre à jour

Si vous avez précédemment mis à jour vers PostgreSQL 18.0, 18.1 ou 18.2, vous devez exécuter le SQL suivant en tant que superutilisateur PostgreSQL dans toutes vos bases de données pour rendre les fonctions json_strip_nulls() et jsonb_strip_nulls() immutables :

UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');

Vous devez également exécuter cette commande dans les bases de données template0 et template1 afin que les futures bases de données créées dans votre instance PostgreSQL aient le bon paramètre de volatilité de fonction. Veuillez consulter la documentation sur les bases de données template pour plus d’informations.

Les utilisateurs n’ayant pas appliqué une ou plusieurs versions peuvent avoir besoin de réaliser d’autres opérations post-mise à jour. Voir les Notes de version pour les détails.

Liens

PGSession 18 : les conférences en replay

Fri, 20 Feb 2026 00:00:00 -0600

Saint-Étienne, le 20 février 2026

La journée Conférences de la PGSession 18 s’est tenue le 14 janvier dernier à Paris. Voici les liens vers les supports de présentation et les vidéos en replay.

Un grand merci aux speakers pour leurs contributions : Alain, Guillaume, Alexy, Jean-Luc, Louise, Damien, Julian, Stefan et Pierrick !.

Les conférences en replay

Les nouveautés de PostgreSQL 18, par Alain Lesage et Guillaume Armède (Dalibo)
Sécuriser les bases de données : de l’audit à l’action avec les recommandations CIS, par Alexy Mace & Jean-Luc Benhaim (Michelin)
Tout ou presque sur les statistiques, par Louise Grandjonc Leinweber (Snowflake, VIP Tech)
PostgreSQL Anonymizer 3.0 : Réplication Masquée, Anonymisation en Parallèle et bien plus encore !, par Damien Clochard (Dalibo)
Terraformer PostgreSQL : OpenTofu + PG, par Julian Vanden Broeck (Dalibo)
Patroni + pgBackRest : le duo gagnant, par Stefan Fercot (Data Egret)
CloudNativePG, ou comment embarquer un éléphant sur Kubernetes !, par Pierrick Chovelon (Dalibo)
Chiffrement Transparent des Données : État de l’art et Perspectives !, par Damien Clochard (Dalibo)

Les autres liens utiles

Enfin, nous remercions chaleureusement notre prestataire Chapeau rouge pour son accompagnement vidéo, toujours efficace et sympathique.

Bon visionnage !

Des questions, des commentaires, des suggestions ?

Écrivez-nous à contact@pgsessions.com.

Plongez dans le monde de CloudNativePG #10 - Mise à jour des Nodes et PDB

Thu, 19 Feb 2026 00:00:00 -0600

Lyon, le 19 février 2026

CloudNativePG ou comment embarquer un éléphant sur un porte-conteneurs !

Lorsque l’on associe PostgreSQL et mise à jour, la première chose qui vient en tête est la mise à jour des binaires PostgreSQL. Si les instances sont déployées avec CloudNativePG, la gestion des versions de l’opérateur est également à prendre en compte.

Et Kubernetes dans tout ça ? Quel est l’impact d’une mise à jour de l’orchestrateur sur nos instances ? Voyons tout cela dans ce nouvel article.

Versions de Kubernetes et drain

Les nouvelles versions de Kubernetes sont disponibles très fréquemment. Seules les trois dernières versions mineures sont maintenues (actuellement 1.33, 1.34 et 1.35) et leur durée de vie est assez courte, généralement autour d’un an pour les dernières versions. Pour vous donner un exemple, la version 1.35 est sortie en décembre 2025 et ne sera plus supportée en février 2027.

Le cycle de vie est relativement rapide et il vous faudra mettre à jour vos Nodes … où se trouveront vos instances PostgreSQL. Cela aura donc un impact sur celles-ci et sur les applications qui s’y connectent.

La documentation Kubernetes donne les grandes lignes d’une mise à jour d’un cluster Kubernetes. Sans rentrer dans les détails, les Pods de vos instances PostgreSQL seront nécessairement évincés pour être redéployés sur d’autres nœuds. On parle de drain. Une opération de drain marque le nœud comme unschedulable et évince (comprendre détruit) les Pods.

Prenons un Cluster postgresql-prod avec deux instances.

$ kubectl get cluster postgresql-prod 
NAME              AGE    INSTANCES   READY   STATUS                     PRIMARY
postgresql-prod   174m   2           2       Cluster in healthy state   postgresql-prod-1

Les Pods postgresql-prod-1 et postgresql-prod-2 vont être supprimés des nœuds sur lesquels ils fonctionnent pour pouvoir mettre à jour le nœud.

Supprimer les Pods PostgreSQL ? Heu comment ça ?… Peut-on au moins avoir la main sur l’opération ? C’est ici que rentre en jeu les ressources PodDisruptionBudget, ou PDB, ressource native de Kubernetes.

Ressource PodDisruptionBudget

Un PodDisruptionBudget est créé par défaut pour chaque Cluster. C’est CloudNativePG qui se charge de cela. Cette ressource, native de Kubernetes, indique la politique d’éviction des Pods que Kubernetes doit respecter en cas de drain de Nodes. En l’occurrence, elle permet d’indiquer, à Kubernetes, combien de Pods, respectant certains critères, doivent être actifs lorsqu’une perturbation volontaire a lieu (ici la montée de version d’un nœud).

CloudNativePG crée donc une règle spécifique pour nos Cluster PostgreSQL. Le nom est suffixé de -primary. Pour notre exemple, on a donc un PDB postgresql-prod-primary dont voici la définition.

$ kubectl describe pdb postgresql-prod-primary
Name:           postgresql-prod-primary
Namespace:      default
Min available:  1
Selector:       cnpg.io/cluster=postgresql-prod,cnpg.io/instanceRole=primary
Status:
    Allowed disruptions:  0
    Current:              1
    Desired:              1
    Total:                1

Passons en revue les informations disponibles :

Name : est le nom de cette ressource ;
Namespace : le Namespace où elle se trouve. Le même que le Cluster ;
Min available : indique combien de Pods respectant le Selector doivent exister ;
Selector : la liste des labels que doit avoir un Pod, il faut comprendre ici :
- le primaire (cnpg.io/instanceRole) du Cluster postgresql-prod (cnpg.io/cluster) ;

Ce PDB impose donc qu’il y ait toujours une instance primaire pour le Cluster. Il suffit d’un PDB qui ne soit pas respecté pour que, par exemple, le drain du Node ne puisse pas se faire.

Testons cela

Lorsqu’un drain est déclenché sur un Node, CloudNativePG va capter cette information et va déclencher certaines opérations.

Prenons le cas du drain du Node kind-worker où se trouve l’instance primaire postgresql-prod-1.

$ kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE    IP           NODE           
postgresql-prod-1   1/1     Running   0          3h     10.244.1.5   kind-worker    
postgresql-prod-2   1/1     Running   0          179m   10.244.2.6   kind-worker2   

Le PDB impose qu’il y ait toujours une instance primaire disponible. Allons-y, lançons la commande de drain :

kubectl drain kind-worker --delete-emptydir-data --ignore-daemonsets

node/kind-worker already cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/kindnet-h6hpf, kube-system/kube-proxy-swjbl
evicting pod default/postgresql-prod-1
error when evicting pods/"postgresql-prod-1" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod default/postgresql-prod-1
pod/postgresql-prod-1 evicted
node/kind-worker drained

Une première tentative de destruction du Pod postgresql-prod-1 a été infructueuse. Le message d’erreur Cannot evict pod as it would violate the pod's disruption budget est plus que parlant. Quelques instants plus tard, le Pod a bien été évincé :

pod/postgresql-prod-1 evicted.

Entre les deux tentatives, une opération de switchover a été opérée par l’opérateur. Dans les traces du controller, on peut notamment trouver cette trace et l’explication dans le msg :

{
  "level": "info",
  "ts": "2026-02-16T20:12:34.942361272Z",
  "msg": "Current primary is running on unschedulable node, triggering a switchover",
  "controller": "cluster",
  "controllerGroup": "postgresql.cnpg.io",
  "controllerKind": "Cluster",
  "Cluster": {
    "name": "postgresql-prod",
    "namespace": "default"
  },
  "namespace": "default",
  "name": "postgresql-prod",
  "reconcileID": "8c0bc954-a723-4aa6-95f6-2ddf4c5f173e",
  "currentPrimary": "postgresql-prod-1",
  "currentPrimaryNode": "kind-worker",
  "targetPrimary": "postgresql-prod-2",
  "targetPrimaryNode": "kind-worker2"
}

L’instance primaire fonctionne sur un nœud unschedulable (à cause du drain). C’est la cause du switchover déclenché par l’opérateur. Celui-ci va faire en sorte d’élire le Pod secondaire postgresql-prod-2 comme nouveau primaire (targetPrimary). Quelques temps après, on peut voir que l’instance primaire est désormais postgresql-prod-2.

kubectl get cluster
NAME              AGE     INSTANCES   READY   STATUS                                       PRIMARY
postgresql-prod   3h12m   2           1       Waiting for the instances to become active   postgresql-prod-2

À cet instant, un primaire existe bien dans le Cluster postgresql-prod. Il se trouve sur un autre Node que celui qui est en cours de drain. Le PDB étant respecté, l’opération de drain du Node peut se poursuivre avec l’éviction du Pod postgresql-prod-1.

C’est à ce moment-là que vous pourrez faire la montée de version du Node Kubernetes.

Avant de déclencher un drain d’un Node, nous vous suggérons de vérifier qu’il n’existe pas de retard trop important entre vos instances secondaires et l’instance primaire.

Et après ?

Pour les personnes les plus attentives, vous aurez remarqué que le Cluster attend que toutes les instances soient actives.

La commande kubectl cnpg status postgresql-prod retourne le Status suivant : Waiting for the instances to become active Some instances are not yet active. Please wait.

Bien que fonctionnel, le Cluster est en mode dégradé, car l’instance postgresql-prod-1 doit toujours être re-déployée. Le problème ici est notamment dû à la co-localité du PV et du Pod qui n’est pas respectée. L’instance PostgreSQL doit se trouver sur le même Node que celui où se trouve son volume. La co-localité des volumes et des instances doit être prise en compte lors du choix du CSI et de la configuration associée.

Ce n’est pas le cœur de notre article de blog. On vous laissera donc vous rapprocher d’experts Kubernetes, mais gardez en tête cette contrainte de co-localité qui peut exister selon votre choix de système de stockage.

Supposons que la mise à jour du Node se soit bien déroulée, il est possible de redéployer des Pods sur le Node. Pour cela, l’opération de uncordon doit être lancée pour indiquer que le Node peut être de nouveau utilisé.

$ kubectl uncordon kind-worker

node/kind-worker uncordoned

Quelques temps après, le Pod est redéployé et le Cluster est complètement fonctionnel (healthy state).

$ kubectl get cluster

NAME              AGE   INSTANCES   READY   STATUS                     PRIMARY
postgresql-prod   19h   2           2       Cluster in healthy state   postgresql-prod-2

Cas d’un `Cluster` mono-instance

Dans le cas où un drain est effectué sur un Node qui héberge un Cluster mono-instance (instances: 1 dans le YAML) l’éviction du Pod ne se fera pas et le message d’erreur suivant sera affiché en boucle.

error when evicting pods/"postgresql-prod-2" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod default/postgresql-prod-2
error when evicting pods/"postgresql-prod-2" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod default/postgresql-prod-2
error when evicting pods/"postgresql-prod-2" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

Il est possible de désactiver l’utilisation de PDB avec le champ spec.enablePDB dans la définition du Cluster :

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-no-pdb
spec:
  instances: 1
  enablePDB: false

Pour autant que ce soit possible, il n’est pas recommandé de l’utiliser en production.

Conclusion

Nous venons de voir comment CloudNativePG utilise la ressource Kubernetes PodDisruptionBudget pour protéger un Cluster PostgreSQL en cas de drain sur un Node.

Le principe est d’éviter que Kubernetes n’évince une instance primaire de façon brutale lors d’une opération volontaire. Si une instance secondaire existe, une bascule est automatiquement effectuée sur celle-ci.

C’est un mécanisme qui est intéressant de connaître, notamment pour la mise à jour de vos nœuds Kubernetes.

Des questions, des commentaires ? Écrivez-nous !

Formations Dalibo : les prochaines sessions

Wed, 18 Feb 2026 00:00:00 -0600

Saint-Étienne, le 18 février 2026

Administration et Performances de PostgreSQL, Développement avec SQL… Dalibo vous propose des formations en présentiel ou à distance. Voici les dates des prochaines sessions inter-entreprises jusqu’à fin 2026.

Le calendrier des sessions

Rappels

Certifiées Qualiopi, nos formations sont détaillées sur notre site institutionnel. Elles se divisent en 4 cursus : Administration, Performances, Développement et Transition vers PostgreSQL.

Inter-entreprises et en présentiel, elles durent 2 ou 3 journées. Depuis 2020, certaines sessions sont aussi assurées à distance sur 4-5 matinées, de 9h00 à 12h30.

Bon à savoir : vous pouvez aussi nous écrire afin d’organiser des sessions en intra.

ADMINISTRATION

DBA1 : Administration PostgreSQL

9-13 mars, à distance
1-5 juin, à distance
8-10 septembre, à Paris
5-9 octobre, à distance
17-19 novembre, à Paris

DBA2 : Administration PostgreSQL Avancée

24-26 mars, à Paris
1-5 juin, à distance
23-25 juin, à Paris
21-25 septembre, à distance
13-15 octobre, à Paris
30 novembre - 4 décembre, à distance

DBA3 : Sauvegarde et Réplication avec PostgreSQL

31 mars - 2 avril, à Paris
15-19 juin, à distance
29 septembre - 1 octobre, à Paris
24-26 novembre, à Paris
15-17 décembre, à Paris

HAPAT : Haute disponibilité avec PostgreSQL

16-20 mars, à distance
9-11 juin, à Paris
14-18 septembre, à distance
1-3 décembre, à Paris

PERFORMANCES

PERF1 : PostgreSQL Performances

10-12 mars, à Paris
8-12 juin, à distance
7-11 septembre, à distance
13-15 octobre, à Paris
16-20 novembre, à distance
8-10 décembre, à Paris

PERF2 : Indexation et SQL Avancés

31 mars - 1 avril, à Paris
23-24 juin, à Paris
29-30 septembre, à Paris
24-25 novembre, à Paris
15-18 décembre, à distance

DÉVELOPPEMENT

DEVPG : Développer avec SQL

17-19 mars, à Paris
16-18 juin, à Paris
22-24 septembre, à Paris

TRANSITION

DBAADM : Administration PostgreSQL pour DBA expérimentés

uniquement en intra et en présentiel

Contactez-nous

Appelez Jill et Lorraine au + 33 1 83 64 61 88,
ou écrivez à formation@dalibo.com.

Sortie de PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21

Thu, 12 Feb 2026 00:00:00 -0600

Strasbourg, le 12 février 2026

Addendum du 17 février : en raison de régressions liées à la fonction substring et à des arrêts possibles du serveur secondaire, nous vous recommandons de surseoir à la mise à jour. Une nouvelle mise à jour est prévue le 26 février.

Le PostgreSQL Global Development Group a publié le 12 février une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.2, 17.8, 16.12, 15.16, 14.21. Cette mise à jour corrige 5 failles de sécurité et plus de 65 bugs remontés ces derniers mois.

Sécurité

CVE-2026-2003: le type oidvector révèle quelques octets de mémoire

Score CVSS v3.1: 4.3 / Versions supportées vulnérables : 14 - 18

Une validation imparfaite du type oidvector dans PostgreSQL permet à un utilisateur de révéler quelques octets de la mémoire du serveur. Nous n’avons pas exclu la possibilité d’attaques qui réussiraient à y trouver des informations confidentielles, mais elles semblent improbables. Les versions avant PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21 sont concernées. Le projet PostgreSQL remercie Altan Birler pour avoir rapporté le problème.

CVE-2026-2004: l’absence de validation du type d’entrée intarray dans l’estimation de sélectivité permet d’exécuter du code arbitraire.

Score CVSS v3.1: 8.8 / Versions supportées vulnérables : 14 - 18

Dans l’extension intarray de PostgreSQL, l’absence de validation du type d’entrée dans la fonction d’estimation de la sélectivité permet à un utilisateur pouvant créer des objets d’exécuter du code arbitraire en tant qu’utilisateur système. Les versions de PostgreSQL avant 18.2, 17.8, 16.12, 15.16, et 14.21 sont concernées.

Le projet PostgreSQL remercie Daniel Firer, dans le cadre de zeroday.cloud, d’avoir rapporté le problème.

CVE-2026-2005: Un dépassement de tampon dans pgcrypto exécute du code arbitraire

Score CVSS v3.1: 8.8 / Versions supportées vulnérables : 14 - 18

Un dépassement de tampon dans l’extension pgcrypto permet à un fournisseur de texte chiffré d’exécuter du code arbitraire en tant qu’utilisateur système de la base de données. Les versions antérieures à PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21 sont concernées.

Le projet PostgreSQL remercie l’équipe Xint Code, dans le cadre de zeroday.cloud, d’avoir signalé ce problème.

CVE-2026-2006: Une absence de validation par PostgreSQL de la longueur des caractères exécute du code arbitraire

Score CVSS v3.1: 8.8 / Versions supportées vulnérables : 14 - 18

Une absence de validation par PostgreSQL de la longueur des caractères multi-octets dans la manipulation des textes permet à un utilisateur de forger des requêtes et de parvenir à un dépassement de tampon (buffer overrun). Cela suffit pour exécuter du code arbitraire en tant qu’utilisateur système de la base. Les versions antérieures à PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21 sont concernées. Le projet PostgreSQL remercie Paul Gerste et Moritz Sanft, dans le cadre de zeroday.cloud, d’avoir rapporté ce problème.

CVE-2026-2007: Un dépassement de tampon dans pg_trgm heap buffer écrits des données dans la mémoire du serveur

Score CVSS v3.1: 8.2 / Versions supportées vulnérables : 18

Un dépassement de tampon dans l’extension pg_trgm permet à un utilisateur de la base d’effectuer des opérations indéfinies en entrant une chaîne spécialement forgée. L’attaquant a un contrôle limité sur la structure des données écrite, mais nous n’avons pas exclu la possibilité d’attaques menant à une élévation des privilèges. PostgreSQL 18.1 et 18.0 sont concernés. Le projet PostgreSQL remercie Heikki Linnakangas d’avoir signalé ce problème.

Correctifs et améliorations

Cette mise à jour corrige plus de 65 bugs rapportés ces derniers mois. Les problèmes décrits ci-dessous concernent PostgreSQL 18. Certains peuvent également affecter d’autres versions supportées de PostgreSQL.

Correction d’incohérences dans l’extension ltree, relatives à la correspondance de texte insensible à la casse. Si vous utilisez un index sur une colonne ltree, une réindexation peut être nécessaire. Voir la section « Mise à jour » pour d’autres consignes.
Ajouter une contrainte NOT NULL sur une colonne déjà marquée NOT NULL via ALTER TABLE … ADD CONSTRAINT impose maintenant que le nom de la contrainte corresponde au nom existant.
Correction du comportement des triggers lorsque MERGE est exécuté depuis un WITH pour inclure les lignes affectées par le MERGE.
Plusieurs corrections du planificateur de requêtes.
Correction de la recherche de sous-chaînes de texte avec des collations non déterministes.
Plusieurs améliorations de NOTIFY dans la gestion et les rapports d’erreurs.
Utilise la bonne fonction de tri lors des constructions parallélisées d’index GIN.
Correction une gestion incorrecte des sauvegardes incrémentales avec des tables de plus de 1 sGo.
La restauration échoue désormais si les WAL n’existent pas en remontant jusqu’au point de redo indiqué par l’enregistrement de checkpoint.
Correction d’ALTER PUBLICATION pour garantir que les trigger sur événements contiennent bien toutes les options définies.
Divers correctifs dans l’initialisation des slots de réplication.
En réplication logique, le slot de réplication n’avance plus après l’échec d’un worker parallèle apply, évitant ainsi la perte de transactions côté souscripteur.
Correction des rapports d’erreurs en cas d’incohérence de types dans SQL/JSONPath.
Correctif dans l’inlining de fonctions en compilation JIT avec LLVM 17 et ultérieurs.
Nouveau paramètre serveur file_extend_method pour contrôler l’usage de posix_fallocate().
Correctif dans l’autocomplétion psql des options de la commande VACUUM.
pg_dump gère à présent correctement des suppressions de séquences concurrentes, et échoue si l’utilisateur n’a explicitement pas les privilèges de lecture sur la séquence.
Plusieurs correctifs d’amcheck pour l’inspection des btree.
Évite un crash de pg_stat_statements quand une liste IN mélange des constantes et des expressions non constantes.

Cette version intègre également les mises à jour des fuseaux horaires tzdata 2025c, avec juste une correction historiques des horodatages antérieurs à 1976 en Basse-Californie.

Mettre à jour

Si vous avez des index sur des colonnes ltree et que vous n’utilisez pas le fournisseur de collation libc, vous devez réindexer toutes les colonnes ltree après la mise à jour. Vous pouvez utiliser REINDEX INDEX CONCURRENTLY pour minimiser l’impact sur votre système.

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.

Liens

UUID v7 – 80x moins d'I/O pour VACUUM

Fri, 06 Feb 2026 00:00:00 -0600

Mont de Marsan, le 6 février 2026

Le type de donnée Universally unique identifier ou UUID est très apprécié dans les architectures distribuées. En effet, une séquence classique (SERIAL, IDENTITY) ne garantit l’unicité qu’au sein d’une seule base de données, là où un UUID est voulu unique au monde par construction, tout en étant généré localement, sans coordination centrale.

Cependant leur nature aléatoire pose un problème de performance mal connu (sauf des DBA PostgreSQL…): la fragmentation des index. Voyons comment PostgreSQL 18 qui implémente les UUID v7 résout ce problème.

Le problème des UUID v4

La fonction gen_random_uuid(), apparue avec PostgreSQL 13, génère des UUID version 4, c’est-à-dire des identifiants de 128 bits complètement aléatoires. Cette propriété est idéale pour éviter les collisions dans les systèmes distribués, mais elle a un effet de bord délétère sur les performances.

Lorsqu’on insère des lignes avec un UUID v4 comme clé primaire, chaque nouvel UUID atterrit à un endroit aléatoire dans l’index B-tree associé à cette clé. Ceci a pour conséquence que les insertions sont dispersées dans tout l’index, rendant le cache peu efficace : chaque page lue n’est utilisée qu’une fois avant d’être évincée.

La solution : UUID version 7

Les UUID v7, définis par la RFC 9562, résolvent ce problème en intégrant un timestamp dans les premiers bits de l’identifiant. Les UUID générés sont donc naturellement triés par ordre chronologique.

PostgreSQL 18 ajoute de nouvelles fonctions :

uuidv4()                      -- Alias de gen_random_uuid()
uuidv7()                      -- Génère un UUID v7
uuid_extract_version(uuid)    -- Retourne la version (1 à 7)
uuid_extract_timestamp(uuid)  -- Extrait la date de création (v1, v7)

Comparaison

Générons quelques UUID des deux versions pour comprendre les différences :

SELECT uuidv4() AS uuid_v4, uuidv7() AS uuid_v7
FROM generate_series(1, 5);

               uuid_v4                |               uuid_v7
--------------------------------------+--------------------------------------
 f8856df2-1638-4478-81ad-0b1be6ab94b7 | 019c2ada-69d6-794a-bf1c-207ea936bb8c
 6ebf42db-6fa7-4ee5-9427-c010fc298630 | 019c2ada-69d6-7967-abd3-ace26cbbe5d1
 9af32354-efd4-4e85-9c5b-12422cfb8420 | 019c2ada-69d6-796d-95d4-7e1c221fc193
 654fa0c3-7398-4a1a-819d-57d003d8afd6 | 019c2ada-69d6-7972-8f04-314ff096437d
 41bf3daa-76ac-46d1-9174-72e6f9dda78c | 019c2ada-69d6-7976-b785-8b92ae4329c2

Les UUID v7 partagent un préfixe commun (le timestamp) tandis que les UUID v4 sont complètement aléatoires. Ce préfixe commun est la clé de leur efficacité dans les index B-tree.

Impact sur la taille des index

Créons deux tables avec 500 000 lignes chacune :

-- Table avec UUID v4
CREATE TABLE t_uuidv4 (id uuid PRIMARY KEY, data text);
INSERT INTO t_uuidv4
SELECT uuidv4(), 'ligne ' || x
FROM generate_series(1, 500000) AS F(x);

-- Table avec UUID v7
CREATE TABLE t_uuidv7 (id uuid PRIMARY KEY, data text);
INSERT INTO t_uuidv7
SELECT uuidv7(), 'ligne ' || x
FROM generate_series(1, 500000) AS F(x);

VACUUM ANALYZE t_uuidv4, t_uuidv7;

Comparons la taille des index :

SELECT relname AS index, relpages AS pages
FROM pg_class
WHERE relname LIKE 't_uuid%pkey'
ORDER BY relname;

     index     | pages
---------------+-------
 t_uuidv4_pkey |  2434
 t_uuidv7_pkey |  1927

L’index UUID v7 est 21 % plus petit ! Les insertions séquentielles permettent un meilleur remplissage des pages de l’index.

Colocalité des données

Au-delà de la taille, c’est la localité des données qui fait la différence. Regardons où se trouvent physiquement les 10 plus petits UUID de chaque table :

-- UUID v4 : accès par index (10 plus petits UUID)
SELECT id, ctid, (ctid::text::point)[0]::int AS page
FROM t_uuidv4
ORDER BY id
LIMIT 5;

                  id                  |    ctid    | page
--------------------------------------+------------+------
 00001a5f-3538-4f1b-a5c5-0a1a3703a15d | (210,8)    |  210
 000025eb-4928-418f-b418-a5b4693d0f02 | (67,62)    |   67
 00002f6c-ae0b-4eaf-856c-26cb41de7ea0 | (252,97)   |  252
 0000316a-83fb-4cb8-bdee-9f867d20d83a | (3297,33)  | 3297
 0000335b-6c7a-4678-a989-ba5603b69317 | (806,37)   |  806
 ...

Ayant été générés à des moments complètement différents, les 10 plus petits UUID v4, bien que contigus dans l’index, pointent vers des pages dispersées aléatoirement dans la table. Et inversement, les UUID d’une même page de la table sont dispersés dans tout l’index.

-- UUID v7 : accès par index (10 plus petits UUID)
SELECT id, ctid, (ctid::text::point)[0]::int AS page
FROM t_uuidv7
ORDER BY id
LIMIT 5;

                  id                  |  ctid  | page
--------------------------------------+--------+------
 019c2adc-fa3d-7711-ae51-43d144c4a169 | (0,1)  |    0
 019c2adc-fa3e-76e4-9094-94cb6398b0a9 | (0,2)  |    0
 019c2adc-fa3e-770d-baa4-149bd7d53633 | (0,3)  |    0
 019c2adc-fa3e-7716-a416-77105da270a2 | (0,4)  |    0
 019c2adc-fa3e-771d-9679-be4d91be9c8c | (0,5)  |    0
 ...

Avec UUID v7, les plus petits UUID (les plus anciens) sont dans les premières pages de la table. La sélection d’une plage d’id consécutifs sur une table UUID v7 lira des pages contiguës, tandis que sur UUID v4, elle fera des accès aléatoires à travers toute la table. Vous n’avez peut-être pas de requête métier qui font ce genre de sélection d’id, mais nous verrons plus loin qu’une pénalité demeure sur l’efficacité du processus autovacuum.

Tri chronologique natif

Puisque les UUID v7 contiennent un timestamp, ils sont naturellement triables par date de création :

SELECT
    id,
    uuid_extract_timestamp(id) AS created_at
FROM t_uuidv7
ORDER BY id DESC
LIMIT 3;

                  id                  |         created_at
--------------------------------------+----------------------------
 019c2add-08da-77d8-8834-7a34d2075185 | 2026-02-04 22:54:14.746+00
 019c2add-08da-77d2-9ee7-e296fd1bc85a | 2026-02-04 22:54:14.746+00
 019c2add-08da-77cc-837f-e3399d65ffb7 | 2026-02-04 22:54:14.746+00

ORDER BY id équivaut à ORDER BY created_at ! Cette propriété peut vous permettre d’économiser une colonne created_at et son index associé.

Impact sur VACUUM

Un effet de la fragmentation dans les index concerne VACUUM. Lors d’une purge de données anciennes (typiquement DELETE FROM sessions WHERE created_at < now() - interval '30 days'), les lignes supprimées sont :

Dispersées dans toutes les pages avec UUID v4 (insertions aléatoires)
Groupées dans les premières pages avec UUID v7 (insertions chronologiques)

VACUUM peut même bypasser le scan d’index si moins de 2% des pages de la table contiennent des tuples morts. Démonstration :

-- Deux tables de sessions avec 10 000 lignes sur 100 jours
CREATE TABLE sessions_v4 (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    created_at TIMESTAMP NOT NULL,
    data TEXT
);

CREATE TABLE sessions_v7 (
    id UUID DEFAULT uuidv7() PRIMARY KEY,
    created_at TIMESTAMP NOT NULL,
    data TEXT
);

-- Insertion de 10 000 lignes réparties sur 100 jours
INSERT INTO sessions_v4 (created_at, data)
SELECT '2026-01-01'::timestamp + ((i-1) / 100) * interval '1 day',
       repeat('x', 100)
FROM generate_series(1, 10000) i;

INSERT INTO sessions_v7 (created_at, data)
SELECT '2026-01-01'::timestamp + ((i-1) / 100) * interval '1 day',
       repeat('x', 100)
FROM generate_series(1, 10000) i;

-- Réorganisation physique selon l'index UUID (maintenance courante)
CLUSTER sessions_v4 USING sessions_v4_pkey;
CLUSTER sessions_v7 USING sessions_v7_pkey;
VACUUM ANALYZE sessions_v4, sessions_v7;

-- Suppression d'un jour de données (1% des lignes)
DELETE FROM sessions_v4 WHERE created_at < '2026-01-02';
DELETE FROM sessions_v7 WHERE created_at < '2026-01-02';

Exécutons VACUUM (VERBOSE) sur les deux :

-- sessions_v4
INFO:  vacuuming "postgres.public.sessions_v4"
INFO:  finished vacuuming "postgres.public.sessions_v4": index scans: 1
pages: 0 removed, 193 remain, 193 scanned (100.00% of total), 0 eagerly scanned
[…]
index "sessions_v4_pkey": pages: 41 in total, 0 newly deleted, 0 currently deleted, 0 reusable

-- sessions_v7
INFO:  vacuuming "postgres.public.sessions_v7"
INFO:  finished vacuuming "postgres.public.sessions_v7": index scans: 0
pages: 0 removed, 193 remain, 3 scanned (1.55% of total), 0 eagerly scanned
[…]
index scan bypassed: 2 pages from table (1.04% of total) have 100 dead item identifiers

Avec UUID v4, les 100 lignes supprimées (1% des données), VACUUM doit scanner 100 % (!) des pages de la table et effectuer un scan complet de l’index (index scans: 1).

Avec UUID v7, les mêmes 100 lignes sont groupées, VACUUM peut bypasser le scan d’index (index scans: 0) et ne parcourt que 1.55% des pages de la table, l’autovacuum sera d’autant plus efficace, n’ayant que 3 pages à parcourir au lieu de 234 (table + index), soit 78 fois moins !!

Notre exemple, volontairement simplifié, permet d’observer deux phénomènes distincts :

le bypass du scan d’index, optimisation de VACUUM ;
moins de pages à parcourir sur la table.

En production, ces deux effets ne sont pas toujours liés, l’avantage de UUID v7 sera donc généralement moins spectaculaire que dans cette démonstration, mais néanmoins bien réel.

À retenir

Les UUID v7 offrent des index plus compacts, une excellente colocalité des données, un tri chronologique natif et un VACUUM nettement plus efficace. Ils sont particulièrement adaptés aux tables à fort volume d’insertions, aux tables partitionnées par date, et aux systèmes distribués. Les UUID v4 restent pertinents si l’imprévisibilité de l’identifiant est requise pour des raisons de sécurité, mais leur utilisation a des conséquences, que vous pourrez désormais anticiper.

Références

La norme RFC 9562 - UUID version 7 ;
Le commit 78c5e141e sur PostgreSQL ;
Nos formations PERF1 et PERF2 qui abordent l’indexation dans PostgreSQL.

Le blog Dalibo

Sortie de PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23

Annonce de fin de vie de PostgreSQL 14

Vulnérabilités de sécurité

CVE-2026-6472: La commande CREATE TYPE de PostgreSQL ne vérifie pas le droit CREATE de sur tous les schemas

CVE-2026-6473: PostgreSQL sous-dimensionne les allocations à cause d’un débordement d’entier

CVE-2026-6474: La fonction PostgreSQL timeofday() peut divulguer des parties de la mémoire du serveur

CVE-2026-6475: Les commandes pg_basebackup et pg_rewind de PostgreSQL peuvent écraser des fichiers sans lien avec le choix du superutilisateur

CVE-2026-6476: La fonction pg_createsubscriber de PostgreSQL permet une injection SQL via le nom de l’abonnement

CVE-2026-6477: Les fonctions lo_* de la bibliothèque libpq de PostgreSQL permettent au superutilisateur du serveur de réécrire la mémoire de la pile du client

CVE-2026-6478: PostgreSQL divulgue des mots de passe hachés en MD5

CVE-2026-6479: L’initialisation SSL/GSS de PostgreSQL provoque un déni de service, via une récursion non contrôlée.

CVE-2026-6575: La fonction pg_restore_attribute_stats de PostgreSQL accepte des valeurs qui entraînent une lecture au-delà de la fin du tableau de statistiques lors de la planification de la requête.

CVE-2026-6637: Le module PostgreSQL refint permet le dépassement de tampon de pile et l’injection SQL.

CVE-2026-6638: PostgreSQL REFRESH PUBLICATION autorise l’injection SQL via le nom de la table.

Correctifs et améliorations

Mettre à jour

Liens

Manuels Dalibo : leur dernière mise à jour intègre PostgreSQL 18

Rappels utiles

Les manuels

Administration

Développement

Performances

Transition vers PostgreSQL

Le privilège des stagiaires

Plongez dans le monde de CloudNativePG #11 - Exécuter des ordres SQL après la création d'un Cluster

Le besoin

Les trois sections postInit

Exemple d’un ordre SQL

Exemple via ConfigMap

Et si une erreur survient ?

Conclusion

Nouveau workshop dédié à CloudNativePG™

Découvrir CloudNativePG

Liens utiles

Rappel général

Sortie de PostgreSQL 18.3, 17.9, 16.13, 15.17 et 14.22

Correctifs et améliorations

Mettre à jour

Liens

PGSession 18 : les conférences en replay

Les conférences en replay

Les autres liens utiles

Plongez dans le monde de CloudNativePG #10 - Mise à jour des Nodes et PDB

Versions de Kubernetes et drain

Ressource PodDisruptionBudget

Testons cela

Et après ?

Cas d’un Cluster mono-instance

Conclusion

Formations Dalibo : les prochaines sessions

Le calendrier des sessions

Contactez-nous

Sortie de PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21

Sécurité

Correctifs et améliorations

Mettre à jour

Liens

UUID v7 – 80x moins d'I/O pour VACUUM

Le problème des UUID v4

La solution : UUID version 7

Comparaison

Impact sur la taille des index

Colocalité des données

Tri chronologique natif

Impact sur VACUUM

À retenir

Références

Cas d’un `Cluster` mono-instance