Blog Loxodata

PostgreSQL 19 bêta 1

Mon, 08 Jun 2026 14:00:00 +0200

PostgreSQL 19 Bêta 1 publiée

Le PostgreSQL Global Development Group annonce la disponibilité de la première bêta de PostgreSQL 19 en téléchargement.

Cette publication contient un aperçu des fonctionnalités qui seront disponibles dans la version finale de PostgreSQL 19, bien que des modifications puissent intervenir pendant la période bêta.

Vous pouvez trouver des informations sur toutes les fonctionnalités et les changements de PostgreSQL 19 dans les notes de version.

Dans l’esprit de la communauté open source PostgreSQL, nous vous encourageons fortement à tester les nouvelles fonctionnalités de PostgreSQL 19 dans vos systèmes afin de nous aider à éliminer les bogues et autres problèmes. Bien que nous ne vous conseillons pas de faire fonctionner cette publication bêta 1 dans vos environnements de production, nous vous encourageons à trouver des moyens de faire fonctionner votre charge applicative typique avec cette publication bêta.

Vos tests et vos commentaires aideront la communauté à s’assurer que PostgreSQL 19 respecte nos standards de stabilité et de fiabilité pour continuer à en faire la base de données relationnelle open-source la plus avancée du monde. Vous pouvez également vous renseigner sur notre processus de beta testing et comment y contribuer.

Principales fonctionnalités de PostgreSQL 19

Vous trouverez ci-dessous les principales fonctionnalités planifiées pour PostgreSQL 19. Cette liste n’est pas exhaustive : pour la liste complète des fonctionnalités, se référer à la note de publication.

Performance

PostgreSQL capitalise sur le sous-système d’I/O asynchrone introduit dans PostgreSQL 18. Dans cette publication, io_method=worker augmente automatiquement le nombre de processus d’I/O, en se basant sur les nouveaux paramètres io_min_workers et io_max_worker.

Cette publication introduit aussi l’extension pg_plan_advice, qui permet aux utilisateurs de contrôler et stabiliser les décisions du planner, accompagné de pg_stash_advice pour appliquer automatiquement les choix en utilisant les identifiants de requête.

Cette publication apporte des améliorations à VACUUM et aux opérations de maintenance. Autovacuum peut maintenant utiliser de la parallélisation, qui peut être configurée avec le nouveau paramètre autovacuum_max_parallel_workers, et un nouveau système de notation aide à prioriser les tables à traiter par VACUUM. De plus, PostgreSQL 19 améliore VACUUM avec une nouvelle stratégie réduisant automatiquement la quantité de travail en marquant les pages comme visibles tant qu’elles sont requêtées.

Enfin, cette publication ajoute la commande REPACK et son option non bloquante CONCURRENTLY, ce qui permet de reconstruire des tables avec moins de surcharge opérationnelle.

PostgreSQL double les performances des INSERT lorsque des vérifications de clés étrangères interviennent.

De plus, cette publication améliore plusieurs aires de la planification et de l’exécuteur de requêtes, incluant des optimisations sur les anti-join, une utilisation plus large des tris incrémentaux, une agrégation anticipée qui accélère le traitement des lignes, des lectures plus rapides à partir du stockage pendant les lectures séquentielles parallélisées, et une simplification de IS DISTINCT FROM et IS NOT DISTINCT FROM vers les opérateurs <> et = lorsque les données en entrées ne peuvent pas être NULL.

Il y a aussi des améliorations de la montée en charge de LISTEN/NOTIFY impactant les charges multi-channel.

Expérience développeur

PostgreSQL 19 introduit le support de SQL/PGQ, permettant aux utilisateurs d’exécuter des « Property Graph Queries » en utilisant la syntaxe SQL standard.

Cette publication étend aussi les possibilités des requêtes temporelles avec le support de la clause FOR PORTION OF pour les commandes UPDATE et DELETE, complétant le support des contraintes temporelles ajoutées dans PostgreSQL 18.

Cette publication ajoute aussi les commandes ALTER TABLE ... MERGE PARTITIONS et ALTER TABLE ... SPLIT PARTITIONS pour faciliter la réorganisation à la volée des tables partitionnées.

Il y a aussi maintenant le support des lignes retournées en conflit pendant une opération « upsert » utilisant la commande INSERT ... ON CONFLICT DO SELECT ... RETURNING.

PostgreSQL 19 introduit la nouvelle syntaxe GROUP BY ALL, facilitant l’ajout de toutes les colonnes non agrégées et non issues d’une fonction fenêtrée au regroupement.

Cette publication étend les capacités de traitement des chaines de caractères dans JSONPATH avec l’ajout des fonctions lower(), upper(), initcap(), replace(), split_part() et la famille de fonctions trim().

PostgreSQL facilite l’adoption de motifs de requêtes « read-your-writes » lorsqu’on travaille avec des réplicas en utilisant la commande WAIT FOR LSN. Ceci permet à une session d’attendre un changement lié au rejeu d’une position spécifique du log (LSN) sur le replica avant d’exécuter une requête SELECT.

PostgreSQL 19 ajoute aussi de nouvelles fonctions SQL pour récupérer les commandes DDL nécessaires pour recréer des rôles, tablespaces et bases de données, simplifiant l’écriture de scripts et de tâches de migration.

De plus, la fonction random() fonctionne maintenant avec des dates et des horodatages, et le langage PL/Python supporte désormais les déclencheurs sur événement (« events triggers »).

Fonctionnalité liées à la sécurité

PostgreSQL ajoute le support côté serveur de « Server Name Indication » (SNI) à travers un nouveau fichier de configuration : pg_hosts.conf, permettant à un serveur PostgreSQL de présenter différents certificats TLS basés sur le nom demandé par le client.

Il y a aussi un nouveau paramètre password_expiration_warning_threshold, par défaut à 7 jours, avertissant l’utilisateur d’une prochaine expiration du mot de passe.

À la suite des efforts pour la dépréciation de l’authentification md5, cette publication émet un avertissement au client après une authentification md5 réussie. Ceci est contrôlable à travers le nouveau paramètre md5_password_warnings.

Supervision et observabilité

PostgreSQL introduit une nouvelle vue pg_stat_lock, qui rapporte des statistiques par type de verrous, et une vue pg_stat_recovery fournissant une visibilité détaillée sur l’état des opérations de récupération.

Une colonne stats_reset est maintenant disponible dans différentes vues statistiques montrant le moment de la remise à zéro des compteurs.

Les vues pg_stat_progress_vacuum et pg_stat_progress_analyze incluent maintenant une colonne started_by rapportant l’initiateur de l’opération, et la vue pg_stat_progress_vacuum a aussi une colonne mode montrant comment le VACUUM est opéré.

Cette publication permet aussi au niveau de log_min_messages d’être spécifié par type de processus, donnant aux opérateurs un contrôle fin sur chaque partie du système de traces.

De plus, les quantités d’octets de l’écriture de pages pleines (FPW) dans les journaux de transactions (WAL) sont maintenant rapportées dans les messages de traces de VACUUM et ANALYZE, aidant à l’identification des opérations de maintenance produisant de grandes quantités de WAL.

De plus, EXPLAIN ANALYZE supporte maintenant la visualisation des statistiques des I/O asynchrones à travers son option IO, fournissant une meilleure visibilité sur la manière qu’ont les requêtes d’utiliser le sous-système d’I/O asynchrone.

Réplication logique et requêtes fédérées

Dans PostgreSQL 19, la replication logique réplique maintenant les valeurs des séquences, simplifiant les tâches de mise à jour. De plus, la nouvelle syntaxe CREATE PUBLICATION ... EXCEPT vous permet de publier toutes les tables d’une base de données, à l’exception d’un sous-ensemble spécifique, tandis que CREATE SUBSCRIPTION ... SERVER permet à un abonnement d’utiliser en serveur étranger (FOREIGN SERVER), simplifiant la gestion des accès.

PostgreSQL 19 rend possible l’activation de la réplication logique sans redémarrage du serveur. La réplication logique peut maintenant être activée à la demande même lorsque le paramètre wal_level est positionné à replica, et le nouveau paramètre en lecture seule effective_wal_level indique quel est le niveau réel. Ceci réduit le besoin d’activer en avance un niveau de WAL trop élevé lorsque le besoin n’est qu’occasionnel, et évite la rupture de l’activité.

Le pilote de données étrangères de PostgreSQL, postgres_fdw, utilisé pour de la fédération de requête, inclut plusieurs améliorations de performance, dont le « push down » d’opérations sur les tableaux vers le serveur distant, et en récupérant et utilisant les statistiques des tables étrangères pour une meilleure planification locale.

Autres points importants

La période bêta de PostgreSQL a un mode « grease » temporaire pour tenter d’identifier des problèmes de compatibilité du protocole dans l’écosystème. Cette page du wiki contient les informations sur le fonctionnement de la campagne : https://wiki.postgresql.org/wiki/Grease.

PostgreSQL 19 permet l’activation et la désactivation des sommes de contrôle à la volée, sans nécessiter un redémarrage ou une réinitialisation.

Il y a plusieurs changements importants qui méritent une attention particulière dans PostgreSQL 19. La compilation Just-in-time (JIT) est maintenant désactivée par défaut. La valeur par défaut du paramètre default_toast_compression est maintenant lz4, amenant de meilleures performances de compression et décompression par défaut. Le support de l’authentification RADIUS est supprimé. De plus, la commande vacuumdb --analyze-only analyse par défaut les tables partitionnées.

Fonctionnalités supplémentaires

De nombreuses autres fonctionnalités et améliorations ont été ajoutées à PostgreSQL. En fonction des cas d’usage, leur importance peut paraître plus ou moins grande que celles mentionnées ci-dessus. Vous pouvez consulter les notes de publications pour une liste complète des nouveautés et changements : https://www.postgresql.org/docs/19/release-19.html

Tests pour le débogage et la compatibilité

La stabilité de chaque publication de PostgreSQL dépend de vous, la communauté. En testant la version à venir avec votre charge et vos outils de tests, vous pourrez nous aider à trouver les bogues et régressions avant la publication de PostgreSQL 19.

Étant donné qu’il s’agit d’une version bêta, des changements mineurs dans le comportement de la base de données, des détails et des APIs sont toujours possibles. Vos retours et tests aideront à déterminer les ajustements finaux des nouvelles fonctionnalités.

La qualité des tests aide à déterminer le moment de la publication finale.

Une liste des problèmes ouverts est publiquement disponible dans le wiki de PostgreSQL. Vous pouvez rapporter des bogues en utilisant le formulaire présent sur le site web de PostgreSQL : https://www.postgresql.org/account/submitbug/.

Planning Bêta

Il s’agit de la première publication bêta de la version 19. Le projet PostgreSQL publiera autant de bêtas que cela est nécessaire pour tester. Celles-ci seront suivies par une ou plusieurs publications de versions candidates, jusqu’à la publication de la version finale vers septembre/octobre 2026.

Pour plus d’information, veuillez consulter la page Beta Testing.

Liens

Crédits photo : Carlos Gonzalez

Retour sur le PG Day France 2026

Mon, 08 Jun 2026 09:00:00 +0200

Retour sur les journées du PG Day France 2026

Le dernier PG Day France s’est tenu les 3 et 4 juin 2026 à Toulouse, chez MétéoFrance. C’est la deuxième fois que MétéoFrance héberge l’évènement.

Et c’est la troisième fois que le PGDay se tient à Toulouse. Le premier était aussi le premier organisé par PostgreSQLFr (et surtout par Jean-Christophe), en 2008.

LOXODATA, sponsor GOLD sur cette édition, proposait un atelier sur PgBouncer lors de la première journée dédiée aux ateliers techniques (il y avait quatre ateliers en tout).

Philippe Viegas et Jean-Christophe Arnu ont animé un atelier PgBouncer, complètement répétable dans un environnement de test basé sur docker. Vous pouvez ainsi télécharger le support de l’atelier et rejouer les exercices en allant sur le repository du projet gitlab de LOXODATA.

Le soir du premier jour, une soirée communautaire était offerte aux participants au restaurant Monsieur Georges, en centre ville. Un moment très agréable et idéal pour échanger sur PostgreSQL ou tout autre sujet avec les membres de la communauté.

Le lendemain, la journée des conférences battait son plein avec pas moins de six présentations et cinq lightning talks (juste après la pause méridienne).

Le programme est disponible sur le site du PG Day France ici.

Les conférences

Frédéric Delacourt (DataBene) nous a proposé un rappel des différents niveaux d’isolation de PostgreSQL, qui restent parfois méconnus.
Wilfried Roset (OVHCloud) nous a partagé son retour d’expérience sur la mise en place d’un serveur MCP afin d’assurer la revue de PR de ses développeurs lors de changement de schémas de base de données.
Haritabh Gupta (Supabase) nous a présenté les travaux entrepris sur Multigres afin d’assurer à ce proxy une pleine compatibilité avec PostgreSQL.
Luigi Nardi (DBTune) nous a démontré son approche sur le workload fingerprint afin d’avancer sur l’optimisation autonome de PostgreSQL.
Franck Pachot (Microsoft) s’est lancé dans un retour d’expérience autour du modèle Domain-Driven Design et la place de l’administrateur de base de données PostgreSQL dans cette approche.
Vincent Mercier (Amazon) a refermé le train des conférences avec une présentation du partionnement natif dans PostgreSQL et de différents outils facilitant ce partionnement, notamment dans un environnement automatisé.

L’équipe organisatrice a remercié tous les participants et speakers, ces derniers se sont vus remettre des douceurs toulousaines (merci Jean-Christophe).

LOXODATA tient à féliciter l’équipe en charge de l’organisation de l’évènement, en particulier Xavier Simon de MétéoFrance, pour le succès de cette édition 2026. Pas moins de 95 participants étaient inscrits !

Crédit logo: Sylvain Beorchia

PostgreSQL 18.4 et autres correctifs

Mon, 01 Jun 2026 09:00:00 +0200

Le PGDG (PostgreSQL Global Development Group) a publié une mise à jour de toutes les versions supportées de PostgreSQL, incluant 18.3, 17.9, 16.13, 15.17 et 14.22.

Pour la liste complète des changements, se référer à la section Notes de publication.

Notification de la fin de vie de PostgreSQL 14

PostgreSQL ne recevra plus de correctif dès le 12 novembre 2026. Si vous utilisez PostgreSQL dans un environnement de production, nous vous suggérons de planifier une mise à jour vers une version supportée et mise à jour de PostgreSQL. Pour plus de détails, se référer à la Politique de version.

Problème de sécurité

CVE-2026-6472 : exécution de fonctions SQL arbitraires en utilisant CREATE TYPE.

Score CVSS: 5.4 MEDIUM (serveur PostgreSQL)

L’absence d’autorisation lors de la création d’un type (CREATE TYPE) dans PostgreSQL permet à un créateur d’objet de détourner d’autres requêtes utilisant search_path pour trouver des types définis par l’utilisateur, y compris les types définis par extension. Autrement dit, la victime peut exécuter des fonctions SQL arbitraires choisies par l’attaquant. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Jelte Fennema-Nio d’avoir reporté ce problème.

CVE-2026-6473 : exécution de code arbitraire avec les privilèges de l’utilisateur du système d’exploitation exécutant la base de données.

Score CVSS: 8.8 HIGH (serveur PostgreSQL)

Une vulnérabilité de dépassement de capacité d’entier présente dans plusieurs fonctionnalités du serveur PostgreSQL permet à un utilisateur de base de données non privilégié de provoquer un sous-dimensionnement de l’allocation mémoire et une écriture hors limites. Ceci peut entraîner l’exécution de code arbitraire avec les privilèges de l’utilisateur du système d’exploitation exécutant la base de données. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Anemone, A1ex, Xint Code, Jihe Wang, Jingzhou Fu, Pavel Kohout, Petr Simecek, www.aisle.com, Bruce Dang of Calif.io, et Sven Klemm d’avoir reporté ce problème.

CVE-2026-6474 : lecture de portions de mémoire du serveur.

Score CVSS: 4.3 MEDIUM (serveur PostgreSQL)

Une faille de sécurité dans la fonction timeofday() de PostgreSQL, utilisant un format de chaîne externe, permet à un attaquant de récupérer des portions de la mémoire du serveur grâce à des fuseaux horaires spécialement conçus. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Xint Code d’avoir reporté ce problème.

CVE-2026-6475 : écrasement de fichiers sans lien avec l’origine choisie par le superutilisateur.

Score CVSS: 8.8 HIGH (client)

L’utilisation de liens symboliques avec les commandes pg_basebackup (format simple) et pg_rewind de PostgreSQL permet à un superutilisateur d’origine d’écraser des fichiers locaux, comme /var/lib/postgres/.bashrc, et de détourner ainsi le compte système. Le démarrage du serveur après ces commandes implique toujours une confiance implicite accordée à ce superutilisateur, du fait de fonctionnalités telles que shared_preload_libraries. Par conséquent, cette attaque n’a d’incidence concrète que si une action est entreprise entre l’exécution de ces commandes et le démarrage du serveur, comme le déplacement des fichiers vers une autre machine virtuelle ou la création d’un instantané de cette dernière. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Valery Gubanov, XlabAI Team of Tencent Xuanwu Lab, Atuin Automated Vulnerability Discovery Engine, Zhanpeng Liu, Guannan Wang, et Guancheng Li d’avoir reporté ce problème.

CVE-2026-6476 : pg_createsubscriber est vulnérable aux injections SQL via le nom de l’abonnement.

Score CVSS: 7.2 HIGH (client)

Une injection SQL dans la fonction pg_createsubscriber de PostgreSQL permet à un attaquant disposant des droits pg_create_subscription d’exécuter des requêtes SQL arbitraires en tant que superutilisateur. L’attaque est exploitée lors de la prochaine exécution de pg_createsubscriber. Toutes les versions précédant les versions 18.4, 17.10 sont concernées.

Le projet PostgreSQL remercie Yu Kunpeng d’avoir reporté ce problème.

CVE-2026-6477 : les fonctions lo_* de la bibliothèque libpq de PostgreSQL permettent au superutilisateur du serveur d’écraser la mémoire de la pile du client.

Score CVSS: 8.8 HIGH (client)

L’utilisation de la fonction intrinsèquement dangereuse PQfn(..., result_is_int=0, ...) dans les fonctions lo_export(), lo_read(), lo_lseek64() et lo_tell64() de la bibliothèque PostgreSQL permet à l’administrateur du serveur d’écraser la mémoire tampon de la pile du client avec une réponse de taille arbitraire. À l’instar de gets(), PQfn(..., result_is_int=0, ...) stocke des données de longueur arbitraire, déterminée par le serveur, dans une mémoire tampon de taille indéterminée. Étant donné que les commandes lo_export de psql et pg_dump appellent toutes deux lo_read(), l’administrateur du serveur peut écraser la mémoire de la pile de pg_dump ou de psql. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Yu Kunpeng d’avoir reporté ce problème.

CVE-2026-6478 : PostgreSQL divulgue les mots de passe hachés MD5 via un canal de synchronisation caché.

Score CVSS: 6.5 MEDIUM (serveur PostgreSQL)

Une faille de sécurité dans la comparaison des mots de passe hachés MD5 lors de l’authentification PostgreSQL permet à un attaquant de récupérer les identifiants utilisateur nécessaires à l’authentification. Ceci n’affecte pas les mots de passe scram-sha-256, utilisés par défaut dans toutes les versions prises en charge. Cependant, certaines bases de données actuelles peuvent contenir des mots de passe hachés MD5 provenant de mises à niveau depuis PostgreSQL 13 ou une version antérieure. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Joe Conway d’avoir reporté ce problème.

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

Score CVSS: 7.5 HIGH (serveur PostgreSQL)

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 soutenu. Si SSL et GSS sont désactivés, un attaquant peut réaliser la même opération en accédant à une socket TCP de PostgreSQL. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Calif.io en collaboration avec Claude and Anthropic Research d’avoir reporté ce problème.

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.

Score CVSS: 4.3 MEDIUM (serveur PostgreSQL)

La fonction pg_restore_attribute_stats() de PostgreSQL présente une vulnérabilité de lecture au-delà du buffer. En effet, elle accepte des valeurs de tableau de longueur non concordante, 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 d’inférer des valeurs en mémoire au-delà de cette fin de tableau. Les versions 18 précédant la version 18.4 sont concernées.

Le projet PostgreSQL remercie Jeroen Gui d’avoir reporté ce problème.

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

Score CVSS:8.8 HIGH (module contrib)

Une vulnérabilité de type dépassement de tampon de pile dans le module « refint » de PostgreSQL permet à un utilisateur de base de données non privilégié d’exécuter du code arbitraire avec les privilèges de l’utilisateur du système d’exploitation exécutant la base de données. Une attaque distincte est possible si l’application déclare une colonne contrôlée par l’utilisateur comme clé primaire en cascade « refint » et autorise les mises à jour de cette colonne par l’utilisateur. Dans ce cas, une injection SQL permet au fournisseur de valeur de mise à jour de la clé primaire d’exécuter du code SQL arbitraire avec les privilèges de l’utilisateur de la base de données effectuant la mise à jour. Toutes les versions précédant les versions 18.4, 17.10, 16.14, 15.18, et 14.23 sont concernées.

Le projet PostgreSQL remercie Nikolay Samokhvalov d’avoir reporté ce problème.

CVE-2026-6638 : REFRESH PUBLICATION est vulnérable aux injections SQL via le nom de la table.

Score CVSS: 3.7 LOW (serveur PostgreSQL)

Une injection SQL dans la réplication logique PostgreSQL (commande ALTER SUBSCRIPTION ... REFRESH PUBLICATION) permet au créateur d’une table abonnée d’exécuter des requêtes SQL arbitraires avec les identifiants de publication de l’abonnement. L’attaque prend effet lors de la prochaine mise à jour (REFRESH PUBLICATION). Les versions 16, 17 et 18 précédant les versions 18.4, 17.10, 16.14 sont concernées.

Le projet PostgreSQL remercie Pavel Kohout, Aisle Research d’avoir reporté ce problème.

Corrections de bogues et améliorations

Cette publication corrige plus de 60 bogues reportés ces derniers mois. Les problèmes listés ci-dessous concernent PostgreSQL. Certains d’entre eux peuvent aussi concerner d’autres versions de PostgreSQL.

correction du fait que des requêtes pourraient retourner des résultats incorrects lors de l’utilisation d’une collation non-déterministe avec un index unique ;
correction de la perte de défferabilité d’un déclencheur de clé étrangère. Préalablement à ce correctif, une clé étrangère définie en tant que DEFERRABLE INITIALLY DEFERRED se serait comportée comme NOT DEFERRABLE après avoir été définie NOT ENFORCED puis ENFORCED. Si vous avez une clé étrangère avec ce problème, après l’installation de cette mise à jour, vous pouvez corriger cela en passant l’état à NOT ENFORCED puis à nouveau ENFORCED ;
amélioration de la capacité du planner d’appliquer l’élagage des partitions à plus de cas ;
correction de la suppression des self-join afin de prendre en compte les colonnes booléennes, par exemple ON t1.boolcol ;
correction de plusieurs problèmes concernant les colonnes générées virtuelles, incluant le fait que INSERT ... ON CONFLICT fonctionne lorsque EXCLUDED référence une colonne générée virtuelle ;
reporte une erreur de sérialisation lorsque MERGE rencontre une ligne mise à jour simultanément dans les modes d’isolation « repeatable read » ou « serializable » ;
correction de la commande CREATE TABLE ... LIKE ... INCLUDING STATISTICS pour les cas où la table source a eu une ou plusieurs colonnes supprimées ;
correction de WITHOUT OVERLAPS pour permettre les domaines ;
désactive la construction d’un type composite avec lui-même via un type multirange ;
correction de résultats parfois incorrects lorsque array_agg(anyarray) est exécuté en parallèle ;
prévention de la fragmentation lors de la restauration d’une sauvegarde incrémentale ;
prévention du blocage de la promotion d’une instance secondaire à cause d’un processus de synchronisation de slot de réplication logique bloqué ;
correction de la colonne pid de la vue système pg_aios pour afficher NULL à la place de 0 lorsqu’une entrée n’est pas propriétaire du processus ;
correction de cas où la vue pg_stat_replication montre un lag NULL quand bien même la réplication est active ;
affichage correcte d’alias de variables d’un JOIN lorsqu’elles sont utilisées dans un GROUP BY ;
en cas d’échec du processus de démarrage, arrête proprement les autres processus enfants avant d’arrêter le postmaster ;
correction d’une erreur d’exécution concurrente pouvant entraîner une boucle d’arrêt-démarrage lorsqu’une instance secondaire suit les journaux de log (WAL) dans une instance primaire d’une version mineure plus ancienne ;
prévient l’attente infinie de l’arrêt d’un processus walsender lorsque la réplication logique est active ;
s’assure que l’écriture de la FSM persiste pendant une restauration. Ceci pourrait avoir des conséquences sur les performances sur une instance secondaire après une promotion ;
corrections de bogues lors de la décompression de sauvegardes et dans le code de lecture des fichiers Tar utilisé par pg_basebackup et pg_verifybackup ;
rétabli le fait que pg_dumpall n’évite pas les droits de rôle de «grantor» suspendu, comme avant PostgreSQL 16. Émission d’un message d’avertissement à propos du «grantor» manquant si le serveur est pls récent que PostgreSQL 16 ;
correction de pg_upgrade pour utiliser la version correcte du protocole lors de la connexion à de plus vieux serveurs ;
correction de la sorte de pg_overexplain lors de l’utilisation de l’option RANGE_TABLE ;
correction d’une défaillance de postgres_fdw à cause d’un nettoyage prématuré d’une connexion en échec.

Cette publication met aussi à jour les fichiers de données des fuseaux horaires à la publication 2026b, dans laquelle la Colombie-Britannique (America/Vancouver) sera toute l’année à UTC-07 (dans les faits, DST) à partir de novembre 2026. Cette publication prend en compte le fait que leur abréviation de fuseau sera MST à partir de ce moment (quoique ça pourrait changer). Il y a aussi une correction historique pour la Moldavie, qui a utilisé l’heure EU DST en transition depuis 2022.

Mise à jour

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

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

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

Liens

Si vous avez des corrections ou suggestions sur cette annonce de publication, merci de les envoyer à la mailing liste publique pgsql-www@lists.postgresql.org.

Meetup du 7 avril 2026 PostgreSQL à Toulouse

Thu, 09 Apr 2026 11:01:00 +0200

Meetup `UPDATE meetup SET location='Pictarine' WHERE group='TLSPUG';`

Après un redémarrage réussi des meetups sur Toulouse et une confirmation au mois de janvier chez Météo-France pour une seconde session, c’est chez Pictarine que s’est déroulé le troisième meetup de la série. Nous tenons à remercier Pictarine pour son accueil (lieu, boisson et nourriture) toujours aussi amical et agréable dans des locaux « au top » (c’est le qualificatif que j’ai le plus entendu dans la soirée pour les décrire). LOXODATA a également agrémenté la soirée d’œufs en chocolat.

Plusieurs nouvelles sur ce groupe d’ailleurs, la première est que Toulouse PostgreSQL User Group a été officiellement reconnu par la communauté et bénéficie donc de la force de communication du site officiel. La seconde est que le groupe a dépassé la centaine d’abonnés sur le site meetup, ce qui est très encourageant. D’ailleurs, le rendez-vous a regroupé environ 25 personnes, ce qui n’est pas si mal pour une troisième session!

Les personnes venues à ce meetup ont pu assister à deux conférences de 30 minutes :

Mohamed Nossirat nous a présenté la façon la plus rapide de charger des données dans PostgreSQL avec Python. Il a notamment considéré qu’il n’avait pas la main sur les données et a décrit son cheminement pour effectuer les chargements à la fois de manière rapide et également en consommant le moins de mémoire possible. Un pari gagné grâce aux itérateurs et à psycopg2.
Pierre Fersing a ensuite présenté son retour d’expérience pour le choix d’un opérateur PostgreSQL dans Kubernetes, pour les besoins de Bleemeo. Sa présentation a abordé les concepts fondamentaux de Kubernetes, les différents opérateurs testés et pour quelles raisons certains n’ont pas été retenus face à CNPG qui s’est avéré être la préférence. Pierre nous a ensuite montré quelques exemples d’utilisation de CNPG au travers de manifest qu’il a agrémenté de conseils.

Enfin, je suis intervenu pour présenter les nouvelles autour de PostgreSQL et de son écosystème, dans une présentation qui se voulait courte… mais qui ne l’a pas été. Le support peut d’ailleurs être téléchargé ici même.

La prochaine session de meetup PostgreSQL Toulouse devrait se dérouler dans le courant du mois de septembre et les organisateurs (dont je fais partie) n’attendent plus que vos propositions de conférences ou de lieu.

Retour sur le pgDay Paris 2026

Tue, 07 Apr 2026 14:45:00 +0200

Le 26 mars 2026 s’est tenue la 10e édition du pgDay Paris, après les 10 ans en 2025. Cette édition s’est déroulée, comme à son habitude, au sein de l’espace Saint Martin, dans le 3e arrondissement de Paris.

LOXODATA était, comme chaque année depuis le début, sponsor « partner » de l’évènement. Nous avions un stand, et nous avons pu échanger avec les visiteurs qui ont pris le temps de venir nous rencontrer.

Cette année encore, 2 salles de conférences étaient dédiées à l’événement. La seconde était majoritairement attribuée à des conférences faites par des sponsors. Par rapport à 2025, les créneaux étaient de 45 minutes au lieu de 20 pour les sponsors, ce qui a permis des conférences plus étoffées techniquement.

Le programme complet est sur le site du pgDay Paris 2026

Les conférences

Le programme de la journée de conférences comportait douze sessions en anglais, dont quatre étaient réservées aux sponsors, dans la seconde salle. Une seule autre conférence a eu lieu dans cette salle, les autres étaient programmées dans l’auditorium. Comme les années précédentes, une captation vidéo a eu lieu, mais uniquement dans l’auditorium.

Après l’accueil des participants, Boriss Mejías a pris le micro pour nous rappeler la disparition tragique de Simon Riggs il y a 2 ans, et des valeurs qu’il portait et affectionnait.

Ce fut ensuite le moment de la keynote.

A framework for self-driving databases

Luigi Nardi et Marc Linster nous ont parlé de bases de données autonomes en partant sur une analogie : les taxis autonomes de San-Francisco. Au fil de ce déroulement, leurs arguments pointent ce qui leur semble nécessaire selon eux pour avoir une base de données qu’on qualifierait d’autonome. Il ne s’agit pas de tout confier à un agent, mais de se limiter aux opérations courantes, avec des limites connues, tout comme les taxis se contentent de conduire dans des conditions météo précises.

Ils concluent sur les évolutions qui leur semblent importantes pour aller dans cette direction dans la communauté, avec des outils et extensions, mais aussi en ajoutant des fonctionnalités dans le code de PostgreSQL pour faciliter la mise en place de cette gestion autonome.

From Crisis to Control: Detect and Fix Corruptions

Dans la seconde salle, Derk van Veen nous a fait part de difficultés de corruption auxquelles il a eu à faire face. Pour cela, il a dû rentrer plus en détails dans le stockage des données et du TOAST, à l’aide d’extensions comme pageinspect, pg_visibility ou pg_surgery. Ce voyage pas vraiment trivial dans les entrailles de PostgreSQL lui a permis de résoudre certains problèmes, et de mitiger la portée de certains autres, permettant de débloquer le vacuum et de permettre à nouveau l’accès aux données. Tout cela résultait d’une montée de version majeure ayant eu lieu quelques années plus tôt, et qui s’écartait des meilleures pratiques.

postgresql.org: The hidden parts

Dans cette présentation, Magnus Hagander, qui participe à la core team, nous précise qu’il participe aussi à l’équipe infrastructure de la communauté. Cette équipe très importante gère les outils en ligne de la communauté et nécessite des personnes de confiance. Il nous décrit par quelques chiffres le nombre de personnes qui font partie de cette équipe, avec une liste des services et le nombre de machines et d’hébergements associés. Personne n’étant dédié à l’infra, des choix sur la simplicité et le long terme sont régulièrement faits et permettent de continuer à faire fonctionner les services. Ces outils ne sont pas toujours récents ni à la mode, mais ils sont toujours fonctionnels et maintenus, et l’infrastructure continue de bien fonctionner, et ce malgré l’augmentation massive de trafic repérée depuis la venue des bots IA.

Database optimization and reducing global digital pollution

Dans la seconde salle, la conférence animée par Catherine Bouxin a mis en avant l’impact écologique souvent sous-estimé du numérique, en particulier celui des bases de données. Elle a expliqué que la croissance massive du streaming vidéo notamment, entraîne une explosion de la consommation énergétique des data centers. L’importance d’optimiser ses bases de données (index, partitionnement, stockage) permet non seulement d’améliorer les performances et de réduire les coûts, mais aussi de limiter l’empreinte carbone.

Au-delà de la technique, des actions simples ont été évoquées comme adopter un hébergement écoresponsable, limiter la qualité du streaming ou éviter les sauvegardes inutiles. Enfin, elle a insisté sur l’importance d’une approche globale, incluant audits, bonnes pratiques de « green coding » et collaboration avec des experts, pour répondre aux enjeux environnementaux à venir.

Operational hazards of managing PostgreSQL DBs over 100TB

Teresa Lopes nous a parlé de cas peu communs de grosses bases de données qui dépassent les 100 To. Elle a commencé par rappeler que la taille n’est pas le seul problème, le nombre de transactions est aussi un facteur important, surtout dans ce genre de contexte. Elle a abordé quelques solutions qu’elle a pu mettre en place avec succès. En particulier, elle a abordé la gestion des lectures et écritures, les vacuums, les sauvegardes et restaurations, le partitionnement, et la gestion des performances des requêtes. Elle nous a également averti que la conférence n’avait pas pour vocation de nous donner une recette miracle. Chaque cas est différent, mais se poser des questions assez tôt permet de limiter les risques.

Creating a “Dungeon Master” with Postgres and MCP

La conférence de Matt Cornillon proposait une approche mêlant PostgreSQL et intelligence artificielle. L’idée était de montrer comment un agent IA peut gérer une partie de jeu de rôle, en interagissant avec une base de données, pour maintenir l’état du jeu et répondre aux actions des joueurs. La conférence a introduit le concept de MCP (Model Context Protocol) pour connecter une base PostgreSQL à un agent IA, ainsi que la notion de « skills », plus centrée sur l’agent et ses capacités. Une réflexion a été portée sur les skills et la sécurité, dans l’objectif d’éviter les « hallucinations » de l’agent ainsi que l’exécution de requêtes dangereuses. Enfin, Matt a souligné les atouts de PostgreSQL pour ce type d’usage, comme la robustesse, la légèreté, ou l’écosystème riche.

Synchronisation of logical replication slots

Dans la seconde salle, Sébastien Lardière de LOXODATA présentait, quant à lui, une fonctionnalité introduite avec PostgreSQL 17 : la synchronisation des slots de réplication logique. Il s’agit de continuer à utiliser la réplication logique lorsqu’un réplica n’est plus disponible et qu’il a été décidé de promouvoir un standby physique.

PostgreSQL permet de réaliser cette opération, mais un patch en cours est sur le point de permettre la gestion des changements de primaires de manière plus simple, à l’instar de ce qui est pratiqué pour la réplication physique.

Customizing the Wordle Game Experience with PostgreSQL

Dans cette conférence plus étoffée que son ligntning talk de l’année passée, Pavlo Golub a montré comment PostgreSQL peut être utilisé pour personnaliser l’expérience du jeu Wordle. L’idée principale était de recréer et enrichir le jeu directement en base de données, en gérant les listes de mots, les règles de validation et les mécanismes de scoring. Grâce à des fonctionnalités comme la recherche textuelle et le « fuzzy matching », il devient possible de proposer des variantes, comme la recherche des mots similaires. Enfin, les participants ont pu jouer contre l’IA Gemini, avec une victoire pour la salle et une pour l’IA.

Cette conférence illustrait bien le potentiel de PostgreSQL comme plateforme flexible pour créer des expériences ludiques et complètes.

Postgres Therapy Session: What the Elephant Can Learn from Its Rivals.

Pour cette dernière conférence, Mayuresh Suresh Bagayatkar nous parle de fonctionnalités qui existent dans d’autres systèmes de bases de données, ou comme il l’indique en titre politiquement incorrect « que pourrions-nous voler aux autres bases de données ? ». Une courte description de plusieurs fonctionnalités est faite, suivi pour certaines des raisons pour lesquelles elle ne sont pas dans postgres. Pour les fonctionnalités qui pourraient apporter des améliorations, quelques idées sont présentées sur les possibilités de les ajouter.

Conclusion

Cette année, on a pu sentir le virage de l’IA arriver dans les conférences, tant dans les sujets sur l’utilisation des agents par exemple, que sur la forme, avec un certain nombre d’illustrations fabriquées par ces outils.

Sur le contenu, les fondamentaux continuent, avec des sujets originaux. Enfin, c’est bien entendu le côté humain qui est le plus intéressant sur ce genre d’évènement. Bien que le nombre de participants soit inférieur à l’année dernière, les échanges étaient tout de même intéressants lors des pauses.

Nous espérons que l’année prochaine, l’évènement aura de nouveau lieu, et que le public sera de retour, plus nombreux dans l’auditorium.

PostgreSQL 18.3 et autres correctifs

Fri, 27 Feb 2026 11:00:00 +0100

Le PGDG (PostgreSQL Global Development Group) a publié une mise à jour de toutes les versions supportées de PostgreSQL, incluant 18.3, 17.9, 16.13, 15.17 et 14.22.

Cette publication hors cycle corrige des régressions relevées depuis la dernière publication de la 18.2 du 12 février 2026.

Pour la liste complète des changements, se référer à la section Notes de publication.

Corrections de bogues et améliorations

Cette mise à jour corrige plusieurs bogues ayant été signalés après la dernière publication. Les problèmes ci-dessous concernent PostgreSQL 18. Certains de ces problèmes peuvent aussi concerner d’autres versions de PostgreSQL.

correction d’une anomalie où un standby est stoppé sur une erreur de type could not access status of transaction;
correction d’une erreur sur la fonction substring() qui remonte l’erreur invalid byte sequence for encoding sur des valeurs de texte non ASCII si la source de cette valeur est une colonne, et introduit par la correction CVE-2026-2006;
correction de la fonction strict_word_similarity dans pg_trgm qui peut entraîner des résultats incorrects ou des plantages. Cela est dû à une omission dans la correction de CVE-2026-2007;
correction de la volatilité des fonctions json_strip_nulls() et jsonb_strip_nulls() afin qu’elles soient immutables, comme dans les versions précédentes, ce qui permet de les utiliser dans les index. Si vous avez déjà effectué une mise à niveau vers PostgreSQL 18.0 à 18.2, consultez les étapes supplémentaires dans la section « Mise à jour »;
correction des tests NOT NULL dans la sous-requête LATERAL UNION ALL qui peuvent entraîner des résultats de requête erronés;
éviter que les contraintes NOT NULL ne génèrent des conflits de noms avec les contraintes écrites par l’utilisateur;
correction de pg_stat_get_backend_wait_event() et pg_stat_get_backend_wait_event_type() pour qu’elles rapportent les valeurs des processus auxiliaires, comme pg_stat_activity;
correction de la conversion d’une variable de type composite en un type de domaine lors du renvoi de sa valeur à partir d’une fonction PL/pgSQL;
correction de la fonction d’entrée binaire hstore pour éviter les plantages lors de l’entrée de clés dupliquées.

Mise à jour

Si vous aviez mis à jour depuis la version 18.0, 18.1 ou 18.2 de PostgreSQL, vous aurez besoin d’exécuter le script SQL suivant avec un rôle PostgreSQL superuser 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 devrez exécuter cette commande dans les bases de données template0 et template1 pour que les futures bases de données créées disposent du bon type de volatilité pour les fonctions ci-dessus. Vous pouvez vous référer à la documentation sur les bases de données templates.

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

Vous pouvez utiliser les commandes suivantes pour exécuter la requête sur toutes vos bases de données :

for db in $(psql -XAt -c "select datname from pg_database where datname not in ('template0')");
    do psql -d "${db}" -c "UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');";
done

De même, pour l’appliquer sur la base de données template0, vous pouvez utiliser les commandes suivantes :

psql -U postgres <<_EOF_
ALTER DATABASE template0 ALLOW_CONNECTIONS = true; 
\c template0
UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');
\c postgres
ALTER DATABASE template0 ALLOW_CONNECTIONS = false;
_EOF_

Liens

Si vous avez des corrections ou suggestions sur cette annonce de publication, merci de les envoyer à la mailing liste publique pgsql-www@lists.postgresql.org.

PostgreSQL 18.2 et autres correctifs

Fri, 13 Feb 2026 09:00:00 +0100

Le PGDG (PostgreSQL Global Development Group) a publié une mise à jour de toutes les versions supportées de PostgreSQL, incluant 18.2, 17.8, 16.12, 15.16, et 14.21.

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

Pour la liste complète des changements, se référer à la section Notes de publication.

Problèmes de sécurité

CVE-2026-2003 : Le type oidvector divulgue quelques octets de mémoire.

CVSS v3.1 Base Score: 4.3

versions vulnérables et supportées : 14 - 18.

Une validation incorrecte du type oidvector dans PostgreSQL permet à un utilisateur de la base de données de divulguer quelques octets de la mémoire du serveur. Nous n’avons pas exclu la possibilité d’attaques visant à obtenir des informations confidentielles dans les octets divulgués, mais celles-ci semblent peu probables. Les versions antérieures à PostgreSQL 18.2, 17.8, 16.12, 15.16 et 14.21 sont concernées.

Le projet PostgreSQL remercie Altan Birler pour avoir reporté ce problème.

CVE-2026-2004 : L’extension intarray manquant une validation du type d’entrée vers l’estimateur de sélectivité permettant l’exécution de code arbitraire.

CVSS v3.1 Base Score: 8.8

versions vulnérables et supportées : 14 - 18.

L’absence de validation du type d’entrée dans la fonction d’estimation de la sélectivité de l’extension intarray permet à un créateur d’objet d’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.2, 17.8, 16.12, 15.16 et 14.21 sont concernées.

Le projet PostgreSQL remercie Daniel Firer durant le zeroday.cloud, pour avoir reporté ce problème.

CVE-2026-2005 : Débordement de la mémoire tampon de l’extension pgcrypto permettant l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8

versions vulnérables et supportées : 14 - 18.

Un débordement de la mémoire tampon dans l’extension pgcrypto permet à un fournisseur de texte chiffré d’exécuter un code arbitraire en tant qu’utilisateur du système d’exploitation exécutant 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 durant le zeroday.cloud pour avoir reporté ce problème.

CVE-2026-2006 : Absence de validation de la longueur des caractères multioctets permettant l’exécution de code arbitraire.

CVSS v3.1 Base Score: 8.8

versions vulnérables et supportées : 14 - 18.

L’absence de validation de la longueur des caractères multioctets dans la manipulation de texte PostgreSQL permet à un utilisateur de la base de données d’émettre des requêtes spécialement conçues pour provoquer un dépassement de tampon. Cela suffit pour 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.2, 17.8, 16.12, 15.16 et 14.21 sont concernées.

Le projet PostgreSQL remercie Paul Gerste et Moritz Sanft durant le zeroday.cloud pour avoir reporté ce problème.

CVE-2026-2007 : Le débordement de la mémoire tampon de l’extension pg_trgm écrit un motif dans la mémoire du serveur.

CVSS v3.1 Base Score: 8.2

versions vulnérables et supportées : 18.

Un débordement de la mémoire tampon dans l’extension pg_trgm permet à un utilisateur de la base de données d’obtenir des effets inconnus via une chaîne de caractères spécialement conçue. L’attaquant a un contrôle limité sur les modèles d’octets à écrire, mais nous n’avons pas exclu la possibilité d’attaques conduisant à une élévation des privilèges. Les versions antérieures à PostgreSQL 18.1 et 18.0 sont concernées.

Le projet PostgreSQL remercie Heikki Linnakangas pour avoir reporté ce problème.

Corrections de bogues et améliorations

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

correction de la correspondance incohérente de texte insensible à la casse dans l’extension ltree. Si vous utilisez un index sur une colonne ltree, vous devrez peut-être, dans certains cas, effectuer une réindexation. Reportez-vous à la section « Mise à jour » pour obtenir des instructions supplémentaires;
la commande ALTER TABLE ... ADD CONSTRAINT pour ajouter une contrainte NOT NULL à une colonne déjà marquée comme NOT NULL nécessite désormais que le nom de la contrainte corresponde au nom de la contrainte existante;
correction du comportement du déclencheur lorsque MERGE est exécuté à partir d’une requête WITH afin d’inclure les lignes affectées par MERGE;
correctifs sur le planificateur de requêtes;
correction de la recherche de sous-chaînes de texte pour les collations non déterministes;
correctifs pour la gestion et le signalement des erreurs NOTIFY;
utilisation de la fonction de tri correcte dans les constructions parallèles d’index GIN;
correction du traitement incorrect des sauvegardes incrémentales avec des tables de plus de 1 Go;
arrêt de la restauration si le WAL n’existe pas jusqu’au point de reprise indiqué par l’enregistrement du checkpoint;
correctif pour ALTER PUBLICATION pour garantir que les déclencheurs d’événements contiennent toutes les options définies;
correctifs concernant l’initialisation des slots de réplication;
mise en pause du slot de réplication après un échec d’application d’un worker parallèle de réplication logique afin d’éviter la perte de transactions côté abonné;
correctif du rapport d’erreurs pour les incompatibilités de type de chemin SQL/JSON;
correction de l’inlining de la fonction de compilation JIT lors de l’utilisation de LLVM 17 ou ultérieure;
ajout d’un nouveau paramètre serveur file_extend_method pour contrôler l’utilisation de posix_fallocate();
correction de la complétion auto de l’utilitaire psql pour les options de la commande VACUUM;
correctif pour pg_dump pour gérer correctement les suppressions simultanées de séquences et échouer si l’utilisateur appelant ne dispose pas explicitement des privilèges nécessaires pour lire la séquence;
correctifs pour amcheck concernant l’inspection btree;
empêcher le plantage de pg_stat_statements lorsqu’une liste IN contient à la fois des constantes et des expressions non constantes;

Cette publication met également à jour les fichiers de données de fuseaux horaires vers la version 2025c de tzdata, qui ne comporte qu’une modification des données historiques pour les horodatages antérieurs à 1976 à Baja, en Californie.

Mise à jour

Si vous avez des index sur des colonnes ltree et n’utilisant pas le fournisseur de collation libc, après la mise à jour vers la dernière version, vous devrez réindexer les données de type ltree. Vous pouvez utiliser REINDEX INDEX CONCURRENTLY pour réduire l’impact sur votre système.

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

Liens

Si vous avez des corrections ou suggestions sur cette annonce de publication, merci de les envoyer à la mailing liste publique pgsql-www@lists.postgresql.org.

De retour du FOSDEM PGDay 2026

Tue, 10 Feb 2026 09:30:00 +0100

De retour du FOSDEM PGDay 2026

Le 30 janvier 2026 s’est déroulé le FOSDEM PGDay, un événement annuel entièrement dédié à PostgreSQL, organisé à Bruxelles en amont du FOSDEM. Cette conférence marque le début de la saison des conférences PostgreSQL en Europe.

L’édition 2026 nous a offert un programme varié, couvrant à la fois les mises à jour majeures sans interruption de service, l’optimisation des performances et l’analyse statistique avancée. Les sessions ont également exploré en profondeur le fonctionnement interne de l’exécuteur, les mécanismes de détection et de correction des corruptions, ainsi que de nombreux retours d’expérience sur la performance sur Kubernetes et bien entendu du vibe coding au-dessus de PostgreSQL managé dans le cloud.

Zero-Downtime Upgrades: PostgreSQL and OS/glibc at Global Scale

Alexander Sosna

Ce retour d’expérience de GitLab décrit une stratégie d’upgrade PostgreSQL réellement sans interruption à très grande échelle (40–60 To, multi-zones), où seule la réplication logique s’est révélée viable. Le pilotage repose sur l’Apdex afin de mesurer l’impact utilisateur réel des opérations. L’architecture combine pg_upgrade sur un nœud cible, resynchronisation logique et possibilité de rollback. Un point critique concerne les upgrades OS/glibc et les collations, traitées via une gestion fine et progressive des index, entièrement automatisée.

Efficiently approximating/estimating percentiles and histograms

Tomas Vondra Le calcul des percentiles et quantiles est une opération analytique courante, mais coûteuse lorsqu’il est exact. Cette présentation montre comment y répondre à l’aide de méthodes d’approximation, en s’appuyant notamment sur les extensions tdigest et ddsketch. Tomas y expose les principes sous-jacents à ces types de données et leur utilisation pratique, en particulier pour produire des histogrammes offrant une représentation lisible des distributions.

Storage Performance Matters: Benchmarking PostgreSQL on Kubernetes

Jonathan Battiato

L’exécution de PostgreSQL sur Kubernetes impose des choix de stockage déterminants pour les performances et la fiabilité, CloudNativePG fournissant un cadre de gestion natif, mais volontairement agnostique du stockage. Cette présentation analyse l’impact des comportements internes de PostgreSQL (WAL, buffers, scans séquentiels) sur les performances d’E/S. Elle compare les volumes locaux et les volumes réseau afin d’en mesurer les effets sur les charges de travail. Des retours terrain et des benchmarks (FIO, pgbench) permettent d’identifier les goulets d’étranglement et d’optimiser les plateformes Data sur Kubernetes. Une initiative de containers est, à ce titre, en cours de développement afin de permettre d’automatiser la caractérisation des stockages envisagés pour stocker les données des bases.

Lighting talks

Après la pause déjeuner, c’est le temps du Lighting talks. Les orateurs ont 5 min pour parler d’un sujet autour de PostgreSQL.

Les sujets abordés :

LISTEN / NOTIFY Présenté comme une file sérialisée avec table interne et advisory locks. Très utile, mais peut devenir un hotspot.
One Database to Rule Them All Mise en perspective des bases se disant « compatibles PostgreSQL » via pgscorecard.
RPM Packaging Devrim explique les contraintes réelles du packaging PostgreSQL.
AI Code & PostgreSQL Retour d’expérience critique sur les PR générées par IA.

Batching in Executor

Amit Langote

Cette conférence, très technique, a mis en lumière les limites historiques de l’exécuteur de PostgreSQL, toujours basé sur un traitement tuple par tuple. Malgré des optimisations récentes, ce modèle reste coûteux sur les CPU modernes, notamment pour les workloads analytiques. Amit nous présente un prototype introduisant un traitement par lots de tuples au sein de l’exécuteur. L’idée est de tirer partie à la fois des capacités SIMD des processeurs et de mieux gérer la localité des données dans le cache processeur. Celui-ci repose sur une nouvelle API, une abstraction de batch et des extensions des Table AM. Les premiers résultats sont prometteurs et ouvrent la voie à un exécuteur PostgreSQL plus efficace et orienté batch. Le principe proposé par Amit est de permettre de détecter au plus tôt les cas où les données sont adjacentes en mémoire (SeqScan, par exemple) et de basculer sur le mode Batch dans ces cas. Cela permet de faire coexister à la fois les traitements OLTP standards et ce nouveau mode batch (qui a pour vocation d’adresser les trafics OLAP).

From Crisis to Control: Detect and Fix Corruptions

Derk van Veen

Un sujet redouté de tous les DBA : la corruption de données dans PostgreSQL. Derk partage son retour d’expérience concret sur des corruptions réelles, parfois anciennes, pour lesquelles une restauration depuis les sauvegardes n’était pas toujours possible. La présentation détaille tout le processus, depuis la détection de la corruption et le déblocage du vacuum jusqu’aux choix techniques permettant de limiter l’impact et corriger le problème. Cette présentation a mis en évidence la nécessité d’une compréhension fine du fonctionnement interne de PostgreSQL et l’usage combiné de plusieurs extensions spécialisées. Une session très pédagogique, qui donne de véritables clés pour affronter les corruptions avec méthode et confiance, et éviter la perte de données.

Pour plus de détails, il a écrit un article sur le sujet “Database corruption in PostgreSQL”.

Vibe-coding with Postgres: really?

Matt Cornillon

Cette présentation de fin de journée était rafraîchissante : comment faire évoluer une application web python en utilisant PostgreSQL avec des agents IA pour réaliser l’implémentation de nouvelles fonctionnalités utilisant des “embeddings”. Matt nous a montré comment, à l’aide de plusieurs agents (un pour le code, un pour la base) et Gemini, il a pu implémenter une fonctionnalité étendue de recherche sur un site web fictif de vente de fleurs. Outre l’agent générant le code python, nous avons pu voir comment l’agent PostgreSQL utilisé dans ce projet a repris le schéma pour le transformer. Cela passe par l’analyse de l’existant par l’agent et la proposition d’implémentation (que le développeur peut modifier) avant que les agents effectuent les modifications réellement.

Conclusion :

Le FOSDEM PGDay 2026 confirme son positionnement de conférence technique, orientée production réelle et évolution du moteur PostgreSQL. Pour un consultant PostgreSQL, c’est un événement à forte valeur ajoutée.

Retour sur le DevFest Toulouse 2025

Fri, 14 Nov 2025 15:00:00 +0100

Retour sur le DevFest Toulouse 2025

Le DevFest Toulouse 2025, organisé par le GDG Toulouse, s’est tenu le jeudi 13 novembre au centre de congrès Diagora à Labège, dans l’Est Toulousain.

Il y avait six salles en parallèle pour offrir des conférences sur des sujets techniques variés allant des langages de programmation, aux méthodes de développement, à l’infrastructure, au frontend et l’IA.

Une salle dédiée aux sponsors permettait d’échanger avec les équipes autour d’animations et de cafés.

Les conférences

Au vu du nombre de conférences, il faut faire des choix. Je vous présente donc ici les conférences auxquelles j’ai pu participer durant la journée.

Vous pouvez consulter l’agenda complet pour visualiser la liste complète des conférences.

Another World, une belle leçon d’architecture logicielle, Olivier Poncet : la conférence d’ouverture permet de revenir sur l’architecture du célèbre jeu Another World créé par Éric Chahi et de son portage par Olivier pour le faire tourner dans un navigateur avec WebAssembly.
Docker Bake, élégance et standardisation pour le build de vos images Docker, Mazlum Tosun : Mazlum nous présente l’outil Docker Bake basé sur Docker Buildx pour construire vos images Docker de manière déclarative avec le format HCL, et de manière concurrente.
Toute ma stack est dans ma BDD : Postgres et quelques “power tools” pour mon backend, Mathieu Passenau et Loïc des Rochettes : Mathieu et Loïc de chez Please-open.it nous présentent leur idée d’utiliser PostgreSQL pour toute la pile logiciel, en passant par le stockage, l’authentification via Keycloak, l’utilisation de fonctions pour la partie contrôleur et les APIs via PostgREST.
Conception de logiciels : le match humains vs AI, Olivier Azeau : Olivier nous propose de participer à un quiz sur la conception logiciel et de comparer nos résultats avec ceux obtenus avec l’aide de l’IA.
Renovate à la rescousse : Automatisez la dette technique de votre infra Kubernetes, Paul Vulliemin : Paul nous propose de découvrir l’outil Renovate pour la mise à jour des dépendances d’outils dans le cadre de l’Infrastructure as code/Continous delivery avec un cluster Kubernetes.
Metal-As-A-Service : Gérer votre bare-metal en MaaS, comme si c’était une machine virtuelle !, Julien Briault : Julien nous présente le cloud du coeur mis en place aux restos du coeur et l’utilisation d’un outil open source pour gérer ses serveurs physiques aussi simplement qu’une machine virtuelle afin de réduire les coûts d’exploitation du matériel.
REX: une approche moderne de gestion de clusters Kubernetes : Alexandre Dias et Thomas Martin de chez Qonto nous présentent leur retour d’expérience sur l’administration de leurs clusters Kubernetes dans une optique de réduction des coûts, de facilité de gestion et de résilience de la production.
Beyond agile : Dans les coulisses des licornes géantes de la Tech !, Rachel Dubois : Rachel nous propose une conférence sur les bonnes pratiques utilisées par des grandes sociétés de la tech dans l’agilité afin d’innover, et comment échouer leur permet de livrer des expériences utilisateurs toujours plus appétentes.

Conclusion

Cette édition du DevFest Toulouse montre à quel point les communautés de développeuses et développeurs sont dynamiques un peu partout en France.

PostgreSQL Conference Europe 2025

Wed, 05 Nov 2025 11:10:00 +0100

Retour sur la PostgreSQL Conference Europe 2025

Cette année, la PostgreSQL Conference Europe 2025 s’est déroulée à Riga, en Lettonie. Cet évènement autour de PostgreSQL rassemble le plus grand nombre de participants en Europe.

La liste des conférences est disponible sur le site de l’évènement : https://2025.pgconf.eu/. Les supports de présentations, ainsi que les enregistrements vidéos sont également mis à disposition dans la mesure du possible.

Community events day

Le mardi, pour la première fois cette année, était consacré à la communauté.

La journée était découpée en ateliers d’une demi-journée. Les ateliers étaient aussi divers qu’intéressants.

Le nombre de places était limité, ce qui a engendré un peu de frustration.

PostgreSQL on Kubernetes Summit

De nombreuses interventions d’une dizaine de minutes devaient permettre de dresser un état des lieux des opérateurs autour de PostgreSQL. Malheureusement, la plupart des présentations ont été consacrées à l’opérateur CloudNativePG.

Celui-ci présente toutefois un réel intérêt, puisqu’il est désormais complètement libre.

Community Organizers Conf

Un atelier à destination des organisateurs de conférences communautaires, avec des conseils intéressants, et des retours d’expérience.

Encore une preuve, s’il en fallait que la communauté est active et accueillante.

La conférence

Lors de la première intervention de la journée, Magnus Hagander a évoqué le nombre de 650 participants. Encore une très nombreuse audience cette année.

La conférence d’ouverture est donnée par Karen Sandler, de la Software Freedom Conservancy. Le sujet abordé est celui de l’importance des logiciels libres dans le monde actuel.

Les conférences sont ensuite réparties dans différentes salles, avec 4 conférences simultanées, dont une réservée aux sponsors. Nous résumons ici nos notes à propos des présentations auxquelles nous avons assisté.

Performance

Improved Freezing in Postgres Vacuum: From Idea to Commit

L’oratrice Melanie Plageman évoque les travaux entrepris depuis des années pour améliorer le freeze des tuples visibles : de nombreuses tentatives ont été abandonnées, car les solutions expérimentées ne sont pas toujours meilleures que la situation actuelle.

Pour rappel, le freeze d’un tuple visible consiste à oublier la transaction ayant rendu visible la ligne, permettant ainsi le cycle des identifiants de transaction. Un des inconvénients de ces tâches de maintenance est l’amplification en écriture : une même page de données est écrite plusieurs fois si nécessaire, à chaque itération des maintenances.

Finalement, la solution retenue, et livrée avec la version 18 de PostgreSQL, est de freezer autant que possible les lignes pendant un vacuum régulier, diminuant l’amplification en écriture.

AIO in PG 18 and beyond

L’orateur Andres Freund est l’auteur principal d’une nouvelle fonctionnalité de PostgreSQL 18 : les entrées-sorties asynchrones.

Après un rappel des enjeux et des possibilités de cette fonctionnalité, il nous montre les gains potentiels, en intégrant dans le test les travaux en cours pour les futures versions de PostgreSQL.

En effet, si la fonctionnalité actuelle est limitée aux lectures séquentielles et aux lectures « bitmap » des index, les lectures indexées et les écritures sont prévues pour les versions 19, 20 ou 21 de PostgreSQL.

Fast-path locking improvements in PG18

L’orateur Tomas Vondra est un développeur habituel de PostgreSQL et s’est trouvé confronté à un problème de performance d’une requête utilisant un grand nombre de partitions. Cela l’a amené à se pencher sur la façon dont les verrous sont obtenus lors de l’exécution d’une requête, et en particulier le « fast-path locking ». Apparue dans la version 9.2 de PostgreSQL, cette fonctionnalité permet d’avoir un cache local de la table des verrous, mais seulement pour 16 objets, ce qui pose un problème lorsqu’il y a un grand nombre de partitions : les verrous sont alors notés dans la mémoire partagée, ce qui est plus lent.

Tomas Vondra travaille alors pour proposer une solution permettant de noter un plus grand nombre de verrous dans ce cache local : la proposition, présente dans PostgreSQL 18, consiste à utiliser un « set-associative cache » afin d’augmenter le nombre d’entrées possibles avec le même niveau de performance.

L’orateur constate alors le gain de performance, très visible dans les Flame Graphs présentés. Pour terminer, outre la liste de toutes les possibilités que cela ouvre pour les prochaines versions de PostgreSQL, Tomas Vondra remercie l’auteur original de la fonctionnalité, Robert Haas, qui a livré un code de qualité, facilitant les améliorations proposées par la suite, et ce détail est très important pour comprendre pourquoi PostgreSQL est un bon outil : il est bien écrit !

Tracking plan shapes over time with Plan IDs and the new pg_stat_plans

L’orateur Lukas Fittl explique en quoi une nouvelle fonctionnalité de PostgreSQL 18 lui a permis de reprendre une idée déjà présente, mais en l’améliorant pour la rendre utilisable.

La nouveauté de PostgreSQL 18 est la possibilité pour une extension de stocker un identifiant de plan d’exécution, ce qui permet de suivre un même plan au cours de l’exécution d’une requête, à travers les différents « hooks » de PostgreSQL. À cela s’ajoute la possibilité pour une extension d’utiliser des statistiques cumulatives.

L’extension pg_stat_plans permet alors de suivre l’utilisation des plans d’exécution par les requêtes d’une instance PostgreSQL, permettant ainsi des analyses fines des performances de nos requêtes, sans grever les performances de ces dernières.

We have multiple concurrent versions of this title trying to understand MVCC

L’orateur Boriss Mejias revient sur un sujet couramment abordé dans les conférences PostgreSQL, mais toujours nécessaire : la gestion de la concurrence dans PostgreSQL.

La présentation revient sur tous les éléments importants qui sont la conséquence de l’implémentation de MVCC dans PostgreSQL : l’isolation des transactions, la notion de lignes mortes, les raisons pour lesquelles VACUUM est utile et a des conséquences, y compris sur la réplication et le freeze des tuples visibles.

Administration

What implementing pg_tde taught us about PostgreSQL

L’orateur Jan Wieremjewicz détaille le besoin exprimé par de plus en plus d’utilisateurs de PostgreSQL : le chiffrement transparent des données, ou TDE.

Entre autres besoins, il nous rappelle que, pour des raisons règlementaires, le chiffrement sur disque n’est plus suffisant, et que certains utilisateurs ont maintenant besoin d’une solution de chiffrement native dans leur base de données.

L’orateur explique alors la démarche de recension des besoins des utilisateurs pour aboutir à une solution. Un des besoins identifiés est d’utiliser une solution open-source, et dont le code, à terme, est présent dans PostgreSQL.

Les solutions déjà existantes ne correspondant pas, Percona développe alors une réponse aux besoins, avec comme objectif l’intégration dans PostgreSQL.

Ça n’est pas le cas actuellement : Percona propose une version modifiée de PostgreSQL et une extension : pg_tde. Deux patchs proposés, mais pas encore intégrés sont en effet nécessaires pour proposer un chiffrement des tables.

La solution est donc open-source, et utilisable, dans des limites connues, et l’objectif de l’intégration dans PostgreSQL reste à atteindre.

TDE as an Extension: A Different Path for PostgreSQL Encryption

À la suite de la présentation précédente, l’orateur Zsolt Parragi détaille l’implémentation actuelle de pg_tde : quel chemin pour y arriver, qu’est-ce qui fonctionne, que reste-t-il à faire ?

Parsing Postgres logs the non-pgBadger way

L’orateur Kaarel Moppel présente les différentes approches possibles pour analyser les logs d’une instance PostgreSQL : d’outils Unix comme sed/awk, en passant par pgBadger jusqu’au chargement des logs dans une table de PostgreSQL, les possibilités sont nombreuses.

L’orateur présente un nouvel outil : pgweasel, écrit en GO, permettant d’extraire des informations agrégées des fichiers de logs, en visant de meilleures performances que les outils existants. Une réécriture en Rust permet d’ailleurs d’être encore plus rapide qu’en GO.

Barman, past, present, and future of a pioneer community project

Les orateurs Giulio Calacoci et Martín Marqués reviennent sur l’histoire de l’outil Barman, connu et utilisé depuis des années par de nombreux utilisateurs pour mettre en œuvre leurs stratégies de sauvegardes et restaurations des instances PostgreSQL.

Si l’activité de l’outil, sous-entendu, son développement, a été chaotique ces dernières années, il a été décidé de relancer, à travers une communauté d’utilisateurs, la vie de l’outil pour répondre aux besoins actuels.

Why PostgreSQL people should really care about Kafka and Debezium?

L’orateur Dirk Krautschick explique le fonctionnement et l’utilisation du couple Kafka/Debezium pour « consommer » les flux de données d’une instance PostgreSQL.

Debezium est le connecteur utilisé par Kafka pour consommer les données issues du décodage logique des journaux de transactions d’une instance PostgreSQL. Cela permet de concevoir des architectures de données évitant de devoir copier des données ou requêter une base : tous les changements de données sont envoyés dans le flux.

L’orateur mentionne pour finir un nouvel outil : Apache Flink, conçu très récemment !

Table repacking, done right

Les orateurs Álvaro Herrera et Antonin Houska détaillent un besoin très présent pour les administrateurs de bases de données : devoir réorganiser physiquement une table. Après un historique des différentes solutions présentes dans PostgreSQL (VACUUM FULL), les orateurs expliquent la difficulté d’intégrer l’outil pg_squeeze dans PostgreSQL, ce second outil faisant la même chose que la première commande, mais en minimisant le verrouillage de l’objet traité.

En effet, les orateurs proposent le renommage de VACUUM FULL et l’intégration de pg_squeeze dans une commande REPACK et son option CONCURRENTLY. Le patch est en cours d’intégration et a besoin de testeurs !

Operational hazards of managing PostgreSQL DBs over 100TB

L’oratrice Teresa Lopes expose un certain nombre de bonnes pratiques à intégrer lorsque l’on s’attaque à des bases dépassant les 100TB.

Parmi les pistes évoquées, Teresa détaille les opérations de VACUUM, les sauvegardes, et la réorganisation des colonnes en fonction de leur type.

Have you ever wondered, how a cloud platform works?

Les orateurs Maximilian Stefanac et Philipp Thun présentent Cloud Foundry, PaaS utilisé par SAP Business Technology, et reposant sur PostgreSQL.

EXPLAIN: make it make sense

L’orateur Aivars Kalvāns explique ce qu’on peut retirer comme information d’un plan d’exécution PostgreSQL.

Database in Distress: Testing and Repairing Different Types of Database Corruption

L’orateur Josef Machytka revient sur les cas de corruption qu’il a eu à traiter.

Il présente un outil qu’il a écrit pour générer des crashs de bases de données de manière à étudier les solutions envisageables pour corriger les problèmes.

High availibility

Patroni and pgBackRest: better together

L’orateur Stefan Fercot évoque l’intégration de deux outils complémentaires : Patroni pour la haute disponibilité et pgBackRest pour les sauvegardes et restauration des instances PostgreSQL.

Quelles sont les différentes étapes où Patroni utilise pgBackRest : archivage, réinitialisation d’un nœud, bootstrap du cluster. On comprend que pgBackRest intervient aux moments critiques de la gestion des données de PostgreSQL.

Un point important noté par Stefan : pour savoir si tout se passe bien, il est essentiel de lire les logs des trois composants impliqués !

Kubernetes from the Database Out

L’orateur Alastair Turner explique les points importants à savoir lorsqu’on souhaite utiliser PostgreSQL dans un cluster Kubernetes.

Quels sont les composants et concepts utilisés : réseau, stockage, automatisation…

Hazards of logical decoding in PostgreSQL

L’oratrice Polina Bungina revient sur ce qu’implique le décodage logique dans PostgreSQL, au regard de son expérience chez Zalando. En effet, cette technologie est loin d’être simple et peut entrainer des effets de bords désastreux pour une instance de production.

De la définition d’un LSN (Log Sequence Number) à la description d’un slot et des différentes informations qui le constitue, on comprend au fur et à mesure les différents points critiques qui peuvent entrainer de vraies difficultés en cas de problèmes.

En effet, une simple commande de maintenance sur une table répliquée peut entrainer le stockage d’un gros volume de données, en plus des WALs habituels, à cause du réordonnancement des transactions répliquées. Il faut alors surveiller la vue pg_stat_replication_slots.

Patroni: what the blog posts don’t tell you…

L’orateur Cameron Murdoch souhaite ajouter quelques points importants qu’on ne lit pas dans les blogposts habituels sur Patroni, notamment la nécessité de sécuriser les flux vers les différents composants d’un cluster.

Création d’utilisateurs dédiés, de certificats pour des flux sécurisés, procédures de mises à jour des différents composants : autant de points critiques qui doivent faire partie de l’intégration de Patroni, et le plus tôt possible pour éviter d’avoir à corriger plus tard.

Autres

Behind Postgres 18: The People, the Code, & the Invisible Work

L’oratrice Claire Giordano fait le bilan des nombreuses contributions nécessaire à fabriquer PostgreSQL 18 : le code, bien sûr, mais pas seulement : la documentation, les évènements communautaires, les contributions financières : de nombreux acteurs s’associent pour former une communauté riche et diverse !

All about Common Vulnerabilities and exposures in PostgreSQL

L’oratrice Priyanka Chatterjee évoque un aspect mal connu : la gestion des vulnérabilités dans le projet PostgreSQL. Qu’est-ce qu’un CVE, comment le projet PostgreSQL est organisé pour répondre, et qu’est-ce qu’un utilisateur doit comprendre des informations publiées lors de la publication d’un correctif de sécurité.

From Stars to Storage Engines: Migrating Big Science Workloads Beyond Greenplum

L’orateur Joaquim Oliveira, détaille les difficultés rencontrées par l’agence spatiale européenne (ESA) suite au rachat de VMware par Broadcom, et le passage en produit commercial fermé de Greenplum.

L’agence a étudié différentes solutions pour rester dans un monde moins fermé. La décision a finalement été prise de travailler avec la solution Warehouse de EDB.

Bonne nouvelle, WarehousePG sur lequel est basée l’offre d’EDB est open source.

Conclusion

À nouveau, cette conférence a apporté aux quelques centaines de présents de la matière pour l’avenir, en plus des nombreuses rencontres et discussions : la communauté PostgreSQL est plus riche et diverse que jamais !

Plusieurs évènements sur Toulouse à ne pas rater en Novembre

Tue, 28 Oct 2025 16:00:00 +0100

Le mois prochain se tiendra deux évènements sur Toulouse autour du logiciel libre, mais pas seulement : j’ai nommé le DevFest Toulouse et le Capitole du Libre.

Le DevFest Toulouse organisé par le GDG Toulouse qui se tiendra le jeudi 13 novembre à Diagora (Labège), un évènement orienté plutôt développement. Un sujet autour de PostgreSQL sera proposé sur comment constituer toute une pile logicielle avec PostgreSQL.

Le Capitole du Libre organisé par l’association Toulibre qui aura lieu le weekend du 15 au 16 novembre à l’ENSEEIHT (Toulouse), autour du logiciel libre. Vous pourrez participer par exemple à un atelier qui présentera CloudNativePG afin d’opérer PostgreSQL dans un cluster Kubernetes.

J’en profite pour vous rappeler le redémarrage des meetups Toulousains de PostgreSQL. Si vous avez raté l’édition précédente, ça se passait chez Pictarine et organisé par le Toulouse PostgreSQL User Group.

Crédits photo : Arthur Chauvineau

Éviter les chevauchements temporels

Fri, 24 Oct 2025 02:00:00 +0200

Dans un précédent article, nous avons présenté les plages de valeurs. Nous allons voir qu’avec ce type de données, il est possible, entre autres, de mettre en place un contrôle sur les chevauchements de données. Pour cela, faisons un peu de pratique avec la mise en place du modèle de données d’une application de location de vélos, nécessitant une gestion de chevauchement des locations et une recherche de plages de disponibilité.

Nous comparons la mise en oeuvre et les performances d’une plage de dates et la gestion d’intervalles avec l’utilisation de dates de début et de fin utilisant les types scalaires traditionnels.

Plusieurs stratégies existent :

Deux colonnes : start_datetime et end_datetime

La forme la plus classique consiste à stocker les bornes dans deux colonnes. Le problème : aucune contrainte SQL native n’empêche deux lignes de se chevaucher en combinant deux colonnes. Il faut alors recourir à un déclencheur vérifiant, à l’insertion ou la mise à jour, qu’aucune autre réservation n’entre en conflit.

Colonnes range + contrainte d’exclusion

Une solution plus élégante, disponible depuis PostgreSQL 9.2, consiste à utiliser un type range (tsrange, tstzrange, daterange) et une contrainte d’exclusion avec un index GiST.

PostgreSQL 18+ : la clause WITHOUT OVERLAPS

Depuis PostgreSQL 18, il est désormais possible de déclarer cette logique directement dans la clé primaire ou une contrainte unique. Pour cela, on utilise la clause WITHOUT OVERLAPS pour la dernière colonne de la contrainte d’unicité.

Et en pratique

Créons trois tables correspondant aux trois stratégies :

rents_exclude : contient des locations de vélos utilisant le type plage de dates et la contrainte d’exclusion ;
rents_wo_overlaps : les mêmes locations utilisant le type plage de dates et la clause WITHOUT OVERLAPS ;
rents_2_dates : les mêmes locations de vélos que dans la table rents_exclude mais en utilisant deux dates.

Avec deux dates

Voici comment nous pouvons gérer des locations avec une date de début et une date de fin utilisant des types timestamptz.

Nous créons une table contenant l’id de location, les dates et heures de début de la location, de fin de la location et l’identifiant du vélo.

CREATE TABLE rents_2_dates (
    id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    start_datetime timestamptz,
    end_datetime timestamptz,
    bike_id INT,
    CONSTRAINT end_date_sup_start_date_chk CHECK (end_datetime > start_datetime)
);

CREATE INDEX rent2dates_start_datetime_idx ON rents_2_dates USING btree(start_datetime);
CREATE INDEX rent2dates_end_datetime_idx ON rents_2_dates USING btree(end_datetime);
CREATE INDEX rent2dates_bike_id_idx ON rents_2_dates USING btree(bike_id);

Nous utilisons une contrainte CHECK pour vérifier que end_datetime est supérieure à start_datetime.

Nous créons ensuite un déclencheur de contrôle sur les commandes INSERT et UPDATE, et sa fonction en langage PL/pgSQL, assurant l’intégrité des données. Dans le cas présent, il s’agit d’empêcher le chevauchement de périodes de location pour un même vélo :

CREATE OR REPLACE FUNCTION check_rent_datetime_validity()  RETURNS TRIGGER AS
$rents_2_dates$
DECLARE counting_of_existing_rentals TEXT;
DECLARE number_of_rents INTEGER;
BEGIN
    counting_of_existing_rentals := '
    SELECT COUNT(*) AS count_rent
        FROM rents_2_dates
        WHERE (($1 >= start_datetime  AND $1 < end_datetime   )
                OR ($2 > start_datetime AND $2 < end_datetime  ) )
        AND bike_id = $3 ';
    IF (TG_OP = 'UPDATE') THEN
        EXECUTE counting_of_existing_rentals || ' AND id <> $4'
        INTO number_of_rents
        USING
        new.start_datetime
        ,new.end_datetime
        ,new.bike_id
        ,new.id;
    ELSIF (TG_OP = 'INSERT') THEN
        EXECUTE counting_of_existing_rentals
        INTO number_of_rents
        USING
        new.start_datetime
        ,new.end_datetime
        ,new.bike_id;
    END IF;
    IF number_of_rents > 0 THEN
        RAISE EXCEPTION 'Cette plage horaire n''est pas disponible pour bike_id % pour la période % - % ', new.bike_id, new.start_datetime, new.end_datetime ;
        RETURN NULL;
    END IF;
    RETURN NEW;
END;
$rents_2_dates$ LANGUAGE plpgsql;

CREATE TRIGGER trg_check_rent_datetime_validity
  BEFORE INSERT OR UPDATE
  ON rents_2_dates
  FOR EACH ROW
  EXECUTE PROCEDURE check_rent_datetime_validity();

Maintenant que le déclencheur de contrôle est prêt, passons à quelques tests.

Insérons une location pour le vélo d’id 7, le 2025-09-01 de 09:00 à 11:00 et de 12:00 à 18:00 :

\set test_day '''2025-09-01'''::date

INSERT INTO rents_2_dates
  ( start_datetime
    ,end_datetime
    ,bike_id)
VALUES
  (:test_day + interval '09 hour'
    ,:test_day + interval '11 hour'
    , 7
),
  (:test_day + interval '12 hour'
    ,:test_day + interval '18 hour'
    , 7
)
 RETURNING *;

┌─────────┬────────────────────────┬────────────────────────┬─────────┐
│   id    │     start_datetime     │      end_datetime      │ bike_id │
├─────────┼────────────────────────┼────────────────────────┼─────────┤
│ 1       │ 2025-09-01 09:00:00+02 │ 2025-09-01 11:00:00+02 │       7 │
│ 2       │ 2025-09-01 12:00:00+02 │ 2025-09-01 18:00:00+02 │       7 │
└─────────┴────────────────────────┴────────────────────────┴─────────┘

Avec l’outil psql, vous pouvez définir des variables lors de la session avec \set. Pour les tests suivants, nous allons affecter test_day avec la valeur '2025-09-01'::date.

Procédons alors au test d’insertion dans une plage horaire déjà occupée. Tentons d’insérer une location pour ce même bike_id de 10:00 à 15:00 :

INSERT INTO rents_2_dates
  ( start_datetime
    , end_datetime
    , bike_id )
VALUES
  (:test_day + interval '10 hour'
    ,:test_day + interval '15 hour'
    , 7
);
ERROR:  Cette plage horaire n''est pas disponible pour bike_id 7 pour la période 
2025-09-01 10:00:00+02 - 2025-09-01 15:00:00+02
CONTEXT:  PL/pgSQL function check_rent_datetime_validity() line 31 at RAISE

La fonction de contrôle remonte une erreur nous indiquant que la plage horaire n’est pas disponible et la transaction est annulée.

Après le test d’insertion, nous faisons un autre test, de mise à jour cette fois, en élargissant la période de la location 2 (12:00 à 18:00) à 10:00-18:00 empiétant sur la location 1 (09:00 à 11:00).

UPDATE rents_2_dates
  SET start_datetime = :test_day + interval '10 hour'
  WHERE id = 2;

ERROR:  Cette plage horaire n''est pas disponible pour bike_id 7 pour la période 
2025-09-01 10:00:00+02 - 2025-09-01 18:00:00+02
CONTEXT:  PL/pgSQL function check_rent_datetime_validity() line 31 at RAISE

Même phénomène que précédemment, le contrôle de la contrainte géré par la fonction annule la mise à jour et renvoie un message d’erreur avec le label défini.

Plage de dates et contraintes d’exclusion

Utilisant le même principe, nous créons une table en remplaçant les deux colonnes date heure de début et de fin par une colonne de type range, ici un TSTZRANGE :

CREATE EXTENSION btree_GiST;
DROP TABLE IF EXISTS rents_exclude;
CREATE TABLE rents_exclude (
    id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY
    , rent_dates TSTZRANGE
    , bike_id INT
    , EXCLUDE USING GiST (rent_dates WITH &&, bike_id with =)
);

L’index créé est le suivant :

"rents_exclude_rent_dates_bike_id_excl" 
   EXCLUDE USING GiST (rent_dates WITH &&, bike_id WITH =)

Nous avons un index multicolonne dont l’ordre est rent_dates, bike_id.

Pourquoi devons-nous installer l’extension btree_GiST ? La liste des classes d’opérateurs pour un index GiST est assez réduite :

 index_method |  opclass_name  | indexed_type  | is_default 
--------------+----------------+---------------+------------
 gist         | box_ops        | box           | t
 gist         | circle_ops     | circle        | t
 gist         | multirange_ops | anymultirange | t
 gist         | point_ops      | point         | t
 gist         | poly_ops       | polygon       | t
 gist         | range_ops      | anyrange      | t
 gist         | tsquery_ops    | tsquery       | t
 gist         | tsvector_ops   | tsvector      | t

L’extension btree_GiST fournit des classes d’opérateurs GiST supplémentaires équivalentes à celui du Btree pour les types de données numériques, temporelles et texte. Ces opérateurs sont donc utilisables par les index, ce qui permet d’affiner la contrainte d’exclusion. Dans notre cas, en plus de la contrainte de chevauchement && sur la plage de date, on y rajoutera la contrainte de bike_id.

Passons à quelques tests d’insertion et validons le comportement d’exclusion. Prenons le vélo 7 n’ayant pas d’entrées dans la table rent_exclude.

Insérons deux locations : une le 2025-09-01 de 09:00 à 11:00 et une de 12:00 à 18:00.

\set test_day '''2025-09-01'''::date

INSERT INTO rents_exclude ( rent_dates, bike_id )
VALUES
  ( TSTZRANGE (:test_day + interval '09 hour',:test_day + interval '11 hour'), 7 ),
  ( TSTZRANGE (:test_day + interval '12 hour' ,:test_day + interval '18 hour'), 7 )
RETURNING *;

┌─────────┬─────────────────────────────────────────────────────┬─────────┐
│   id    │                     rent_dates                      │ bike_id │
├─────────┼─────────────────────────────────────────────────────┼─────────┤
│ 1       │ ["2025-09-01 09:00:00+02","2025-09-01 11:00:00+02") │       7 │
│ 2       │ ["2025-09-01 12:00:00+02","2025-09-01 18:00:00+02") │       7 │
└─────────┴─────────────────────────────────────────────────────┴─────────┘

Insérons une location pour le vélo 7 sur une période déjà occupée (12:00 à 18:00) :

\set test_day '''2025-09-01'''::date
INSERT INTO rents_exclude(rent_dates, bike_id)
VALUES( TSTZRANGE ( :test_day + interval '11 hour' ,:test_day + interval '17 hour' ) ,7 );

ERROR: conflicting key value violates exclusion constraint "rents_bike_id_rent_dates_excl"
DETAIL: Key (rent_dates, bike_id)=(7, ["2025-09-01 11:00:00+01","2025-09-01 17:00:00+01")) 
conflicts with existing key 
(rent_dates, bike_id=(7, ["2025-09-01 12:00:00+01","2025-09-01 18:00:00+01")).

Comme on le constate, une tentative d’insertion a échoué dans un créneau déjà occupé pour le même bike_id en raison de la contrainte d’exclusion mise en place.

Après le test d’insertion, nous faisons un autre test, de mise à jour cette fois, en élargissant la période de la location 2 (12:00 à 18:00) à 10:00-18:00 en empiétant sur la location 1 (09:00 à 11:00).

UPDATE  rents_exclude 
set rent_dates = TSTZRANGE(:test_day + interval '10 hour',:test_day + interval '18 hour')
where id  = 2;

ERROR: conflicting key value violates exclusion constraint "rents_rent_dates_bike_id_excl"
DETAIL: Key (rent_dates, bike_id)=(["2025-09-01 10:00:00+02","2025-09-01 18:00:00+02"), 7) 
conflicts with existing key 
(rent_dates, bike_id)=(["2025-09-01 09:00:00+02","2025-09-01 11:00:00+02"), 7).

La transaction est annulée et un message d’erreur nous indique une violation de contrainte, car le créneau est déjà occupé pour le même bike_id.

Plage de dates et la clause WITHOUT OVERLAPS

À présent, utilisons la nouvelle fonctionnalité “WITHOUT OVERLAPS”.

Si cette option WITHOUT OVERLAPS est spécifiée pour la dernière colonne, celle-ci est alors vérifiée pour les chevauchements plutôt que pour l’égalité. Dans ce cas, les autres colonnes de la contrainte autorisent les doublons, à condition qu’ils ne se chevauchent pas dans la colonne WITHOUT OVERLAPS.

CREATE EXTENSION btree_GiST;
CREATE TABLE rents_wo_overlaps (
    id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    rent_dates TSTZRANGE,
    bike_id INT,
    UNIQUE (bike_id, rent_dates  WITHOUT OVERLAPS )
);

Dans ce cas, l’index est le suivant :

    "rents_wo_overlaps_bike_id_rent_dates_key" 
    UNIQUE (bike_id, rent_dates WITHOUT OVERLAPS)

L’ordre des colonnes est différent de celui créé pour la table rents_exclude, nous avons bike_id, rent_dates.

Comme pour la contrainte d’exclusion un index de type GiST est créé avec les mêmes types de contraintes. Le comportement est donc le même que pour la table rents_exclude.

Performance et taille sur le disque

Dans cette partie, nous allons contrôler les temps d’insertions avec des volumes conséquents, le volume des index et analyser les temps d’exécution des requêtes.

Performance en insertion

La création du jeu de données s’est effectuée de la façon suivante :

insertion de 1000 vélos de catégorie aléatoire ;
création de trois locations par jour pour chaque vélo sur deux années calendaires.

Ce qui produit une table avec 2 190 000 entrées.

Le jeu de test est produit et inséré sur un ordinateur de bureau avec la configuration par défaut de PostgreSQL.

Vous pouvez trouver l’ensemble du jeu de test sur notre gitlab.

Tout d’abord, comparons les vitesses d’insertions :

Insertion dans la table rents_2_dates, où le contrôle d’intégrité des données se fait par une fonction déclencheur :

set track_functions = 'pl';
select pg_stat_reset();
INSERT INTO rents_2_dates;
INSERT 0 2190000
Time: 244937,342 ms (04:04,937)

Insertion dans la table rents_exclude, où le contrôle d’intégrité des données se fait par contrainte d’exclusion :

INSERT INTO rents_exclude;
INSERT 0 2190000
Time: 148393,870 ms (02:28,394)

Insertion dans la table rents_wo_overlaps, où le contrôle d’intégrité des données se fait par contrainte d’exclusion et clause WITHOUT OVERLAPS :

INSERT INTO rents_wo_overlaps;
INSERT 0 2190000
Time: 119230,806 ms (01:59,231)

Les opérations d’insertion sont plus performantes avec le type range, dans la mesure où le contrôle d’intégrité est assuré directement par la contrainte d’exclusion. En revanche, dans la table rents_2_date, ce contrôle est effectué par un déclencheur qui vérifie pour chaque ligne insérée ou mise à jour, l’absence de tout chevauchement avec les enregistrements existants.

Il est possible d’obtenir certaines informations sur le temps d’exécution de la fonction grâce à la vue pg_stat_user_functions. Pour cela, il faut activer le paramètre track_functions dans la configuration de l’instance.

Dans notre cas, nous avons activé le traçage sur les fonctions PL/pgSQL dans la transaction d’insertion des données via la commande :

set track_functions = 'pl';

Après l’import des données, voici les informations :

 select funcname, calls , (self_time || ' milliseconds')::interval as self_time from pg_stat_user_functions ;
┌──────────────────────────────┬─────────┬─────────────────┐
│           funcname           │  calls  │    self_time    │
├──────────────────────────────┼─────────┼─────────────────┤
│ check_rent_datetime_validity │ 2190000 │ 00:03:51.925302 │
└──────────────────────────────┴─────────┴─────────────────┘

Le temps total d’insertion est de 04 min 05s. 03 min 52s sont occupées par le traitement de la fonction, soit plus de 90% du temps.

Volume des index

L’index GiST est une structure arborescente équilibrée comme le Btree contenant des paires clé, pointeur, mais les clés GiST sont plus complexes qu’un Btree, ce qui amène un volume plus important.

D’un côté, les tables rents_exclude et rents_wo_overlaps disposent d’un seul index GiST spécifique pour le range :

  "rents_pkey" PRIMARY KEY, btree (id)
  "rents_bike_id_rent_dates_excl" EXCLUDE USING GiST (rent_dates WITH &&, bike_id WITH =)

De l’autre, la table rents_2_dates avec trois index de type Btree :

  "rents_2_dates_pkey" PRIMARY KEY, btree (id)
  "rent2dates_end_datetime_idx" btree (end_datetime)
  "rent2dates_start_datetime_idx" btree (tart_datetime)
  "rent2dates_bike_id_idx" btree (stat_datetime)

On trouve ci-dessous un tableau donnant par table le volume des données et le volume des index :

┌─────────────────────────────────────┬────────────┬──────────────┬────────────┐
│             table_name              │ table_size │ indexes_size │ total_size │
├─────────────────────────────────────┼────────────┼──────────────┼────────────┤
│ "ams_rent_bike"."rents_exclude"     │ 126 MB     │ 222 MB       │ 348 MB     │
│ "ams_rent_bike"."rents_2_dates"     │ 126 MB     │ 97 MB        │ 223 MB     │
│ "ams_rent_bike"."rents_wo_overlaps" │ 126 MB     │ 229 MB       │ 354 MB     │
└─────────────────────────────────────┴────────────┴──────────────┴────────────┘

Voyons maintenant le volume de chaque index :

┌───────────────────┬──────────────────────────────────────────┬────────────┬────────┬─────────────────────┐
│     rel_name      │                index_name                │ type_index │  size  │       columns       │
├───────────────────┼──────────────────────────────────────────┼────────────┼────────┼─────────────────────┤
│ rents_wo_overlaps │ rents_wo_overlaps_bike_id_rent_dates_key │ GiST       │ 182 MB │ rent_dates, bike_id │
│ rents_exclude     │ rents_exclude_rent_dates_bike_id_excl    │ GiST       │ 173 MB │ rent_dates, bike_id │
│ rents_2_dates     │ rent2dates_start_datetime_idx            │ btree      │ 17 MB  │ start_datetime      │
│ rents_2_dates     │ rent2dates_end_datetime_idx              │ btree      │ 17 MB  │ end_datetime        │
│ rents_2_dates     │ rent2dates_bike_id_idx                   │ btree      │ 16 MB  │ bike_id             │
└───────────────────┴──────────────────────────────────────────┴────────────┴────────┴─────────────────────┘

Dans notre cas, nous comparons le volume de la somme des trois index btree liés au stockage sur 2 colonnes avec le volume de l’index GiST de la contrainte d’exclusion et avec l’index GisT de la contrainte d’unicité (qui utilise WITHOUT OVERLAPS). Comme nous l’avons indiqué plus haut, la clé dans ce dernier cas contient à la fois les données de la plage de date et le bike_id.

Le volume est différent entre les index GiST car l’ordre des colonnes n’est pas le même. On s’aperçoit également que chaque index GiST est 3x plus volumineux que la somme des 3 index Btree.

Performance de recherche

Voyons à présent une mise en situation. Nous souhaitons connaître les disponibilités des vélos sur une journée donnée.

Vous trouverez les requêtes dans les liens suivants :

Les structures des requêtes sont assez proches les unes des autres ; leur but est de contrôler le bon usage des index et de comparer les temps des réponses.

En ce qui concerne les performances, l’avantage est donné à l’utilisation de deux colonnes.

Table	Temps
`rents_2_dates`	10 ms
`rents_exclude`	15 ms
`rents_wo_overlaps`	30 ms

La différence de temps entre rents_exclude et rents_wo_overlaps est dû a l’ordre des colonnes dans l’index.

Vous pouvez trouver les résultats des EXPLAIN (ANALYSE, buffers) ici :

Prenons un autre exemple, la liste des réservations pour une liste de vélos sur une période donnée :

\set search_range TSTZRANGE('''2025-09-01'''::date + interval '''09 hour''' ,'''2025-09-01'''::date + interval ''' 20 hour''')

EXPLAIN (ANALYSE,BUFFERS)
 SELECT * FROM rents r
 WHERE r.rent_dates && :search_range AND r.bike_id < 100;

\set vstart_datetime '''2025-09-01'''::date + interval '''09 hour'''
\set vend_datetime '''2025-09-01'''::date + interval '''20 hour'''

EXPLAIN (ANALYSE,BUFFERS)
SELECT
  *
  FROM rents_2_dates r
  WHERE
  (
      (start_datetime BETWEEN :vstart_datetime AND  :vend_datetime)
  OR
     (end_datetime BETWEEN :vstart_datetime AND :vend_datetime)
  )
  AND r.bike_id < 100
;

Dans ce cas, la lecture des plans d’exécutions nous indique que, pour l’interrogation des données dans la table rents_2_dates, PostgreSQL parcourt trois index :

rent2dates_start_datetime_idx
rent2dates_end_datetime_idx
rent2dates_bike_id_idx

Ces informations sont visibles dans le fichier rents_for_period_some_bikes_2_dates.txt.

Pour la recherche dans la table rents_exclude, il n’y a qu’un parcours d’index :

rents_bike_id_rent_dates_excl

Ces informations sont visibles dans le fichier rents_for_period_some_bikes_range_exclude.txt.

De plus, nous pouvons constater que moins de blocs de données sont lus.

Pour la recherche dans la table rents_wo_overlaps, il n’y a qu’un parcours d’index :

rents_wo_overlaps_bike_id_rent_dates_key

Ces informations sont visibles dans le fichier rents_for_period_some_bikes_range_exclude.txt.

Dans notre exemple avec une clause where bike_id < 100, le résultat est le suivant :

Table	Temps
`rents_2_dates`	8 ms
`rents_exlude`	0.7 ms
`rents_wo_overlaps`	4 ms

En regardant de plus près le plan d’exécution, une piste d’amélioration sur la requête avec deux dates serait d’ajouter un index sur les trois colonnes start_datetime, end_datetime, bike_id.

CREATE INDEX rent2dates_start_end_bike_id_idx ON rents_2_dates USING btree(start_datetime,end_datetime,bike_id);

Effectivement le temps d’exécution est amélioré, car la requête répond en 1.7ms. Néanmoins, dans ce cas, l’index ajoute un volume de 85Mo.

Voir le fichier rents_for_period_some_bikes_2_date_optim.txt.

Idem pour la table rents_wo_overlaps en créant un index GiST (rent_dates, bike_id).

Voici le plan d’execution.

CREATE INDEX rents_wo_overlaps_rents_date_bike_id ON rents_wo_overlaps USING GiST (rent_dates, bike_id)

Le temps d’exécution est de 0.5ms contre 4ms, mais nous rajoutons un index de 112 Mo.

Après l’ajout des index, nous avons les temps suivants :

Table	Temps
`rents_2_dates`	1.7 ms
`rents_exlude`	0.7 ms
`rents_wo_overlaps`	0.5ms

Conclusion

La gestion des chevauchements temporels est un sujet qui peut devenir un vrai casse-tête lorsqu’il s’agit de modéliser des réservations, des plannings ou des périodes de validité. Le type range facilite la manipulation des données.

Il apporte notamment un avantage indéniable : le contrôle de l’intégrité des données, entièrement géré par la base de données. Même si l’utilisation du type TSTZRANGE ne semble pas naturelle de prime abord, nous pouvons observer qu’une fois mis en place, ce type et les index GiST proposent un ensemble concis et élégant à l’utilisation.

La nouvelle fonctionnalité WITHOUT OVERLAPS apporte une écriture simplifiée mais impose que la contrainte de non-chevauchement se trouve sur la dernière colonne. Dans notre cas, nous avons dû créer un autre index composite avec une meilleure sélectivité sur les premières colonnes.

En ce qui concerne les tests de performance en insertion, l’avantage est en faveur du type range. La contrainte d’exclusion étant intégrée, elle rend l’opération 2,4 fois plus rapide.

Le volume sur disque d’un index GiST est deux à trois fois plus volumineux que la somme des trois index Btree de notre exemple.

Pour l’exécution des requêtes, nous avons testé deux profils de requête : un complexe (CTE, jointure, etc.) et un plus simple (un WHERE dans la table de location). On se rend compte qu’il n’y a pas de grandes différences sur les temps d’exécution.

Meetups PostgreSQL à Toulouse : c'est reparti !

Fri, 10 Oct 2025 15:11:00 +0200

Meetup `pg_ctl restart -D Toulouse`

Par le passé, des meetups PostgreSQL ont eu lieu à Toulouse. L’initiative s’est essoufflée et la pandémie est passée par là.

Mais en novembre 2025, au Capitole du Libre, Geoffrey de Pictarine est venu vers moi après une conférence en évoquant la possibilité de relancer cette initiative. J’ai dit « banco! ».

En juin, Pictarine nous donnait son feu vert pour effectuer cette rencontre dans leurs locaux à Labège Innopole, et nous nous sommes lancés dans l’organisation de l’événement.

Pour cela, nous avions, Geoffrey et moi, chacun un sujet :

Geoffrey a proposé une présentation de la migration de 10 années de business de Datastore vers PostgreSQL. Il y explique les enjeux, la stratégie et les enseignements de cet exercice qui fut un succès pour Pictarine ;
Pour ma part, j’ai présenté les grandes nouveautés de PostgreSQL 18 (dont le support peut être téléchargé ici).

Pour une reprise, c’est une réussite : 22 fans de PostgreSQL ont participé à l’événement !

Après une brève introduction sur le déroulement du meetup, Geoffrey avons enchaîné nos présentations. La soirée s’est terminée par un apéritif dînatoire avec des discussions sur l’utilisation de notre SGBD préféré. Nous avons également parlé de pouvoir participer au DevFest Toulouse cette année. De nombreuses connexions se sont créées lors de cet événement.

Je tiens à remercier encore une fois Pictarine d’avoir rendu ce meetup possible en nous proposant ses locaux et en sponsorisant l’apéritif dînatoire.

Nous nous sommes entendus pour organiser le prochain meetup dans le courant du mois de janvier 2026.

Restauration Point-In-Time d’un cluster Patroni avec pgBackRest

Thu, 02 Oct 2025 08:00:00 +0200

Restauration Point-In-Time d’un cluster Patroni avec pgBackRest

Dans un article précédent, nous avons vu comment mettre en place une réplication logique avec Patroni. Nous allons voir les méthodes de restauration à un instant donné (PITR - Point-In-Time Recovery) avec ce même outil.

Grâce à l’intégration de pgBackRest et Patroni, il est possible de reconstruire proprement un cluster en cas de suppression ou corruption de données — tout en remontant précisément à une date ou une transaction cible.

Prérequis pour la restauration PITR

Avant toute tentative de restauration temporelle, assurez-vous que :

pgBackRest est correctement configuré ;
L’archivage des WAL est activé ;
Au moins une sauvegarde complète est disponible.

Mise en situation : suppression de données

Créons une base de test et insérons quelques lignes dans une table :

CREATE DATABASE pitr_test;
\c pitr_test
CREATE TABLE mytable (
  id INT,
  payload TEXT,
  inserted_at TIMESTAMP DEFAULT now()
);
INSERT INTO mytable SELECT n, 'text_' || n FROM generate_series(0,10) n;
SELECT * FROM mytable;

Résultat :

 id | payload |        inserted_at
----+---------+---------------------------
  0 | text_0  | 2025-07-21 09:14:15.78179
...
 10 | text_10 | 2025-07-21 09:14:15.78179

La transaction d’insertion est identifiable via le champ xmin :

SELECT xmin, xmax, * FROM mytable;

 xmin | xmax | id | payload | inserted_at
------+-------+----+---------+----------------------------
  752 |     0 |  0 | text_0  | 2025-07-21 09:14:15.78179
...

Supposons qu’une action destructive intervienne :

TRUNCATE mytable;

On force ensuite l’écriture des journaux de transaction pour garantir leur archivage :

SELECT pg_switch_wal();
SELECT now();

Étapes de restauration

Nous vous proposons deux méthodes afin de restaurer vos instances à la cible voulue.

Méthode 1 : restauration manuelle du primaire

1. Identifier le nœud primaire

Dans notre exemple, le primaire est pgdeb01.

patronictl -c /etc/patroni/config.yml topology
+ Cluster: loxodemo (7427142939826752414) ------+----+-----------+
| Member    | Host        | Role    | State     | TL | Lag in MB |
+-----------+-------------+---------+-----------+----+-----------+
| pgdeb01   | 10.200.0.11 | Leader  | running   |  3 |           |
| + pgdeb02 | 10.200.0.12 | Replica | streaming |  3 |         0 |
| + pgdeb03 | 10.200.0.13 | Replica | streaming |  3 |         0 |
+-----------+-------------+---------+-----------+----+-----------+

2. Stopper Patroni sur les réplicas

Dans notre exemple, sur pgdeb02 et pgdeb03.

systemctl stop patroni

3. Stopper Patroni sur le primaire

Une fois arrêté, le cluster doit apparaître vide :

patronictl -c /etc/patroni/config.yml topology
+ Cluster: loxodemo (7427142939826752414) ------+
| Member | Host | Role | State | TL | Lag in MB |
+--------+------+------+-------+----+-----------+
+--------+------+------+-------+----+-----------+

4. Restaurer les données sur le futur primaire

On peut choisir n’importe quel nœud du cluster patroni pour effectuer cette opération.

pgbackrest --stanza=loxodemo --delta restore \
  --type=time \
  --target="2025-07-21 09:14:16.78179+00" \
  --target-action=promote

5. Lancer PostgreSQL localement (sans Patroni)

Cette opération s’effectue toujours sur le futur primaire.

su - postgres -c "/usr/lib/postgresql/16/bin/postgres -D /data/postgres/loxodemo ..."

6. Vérifier les logs de PostgreSQL

Extrait typique indiquant la fin de la restauration :

recovery stopping before commit of transaction 753
last completed transaction was at log time 2025-07-21 09:14:15.792863+00

7. Vérifier les données restaurées

Dans un autre terminal, lancez psql sur la base à vérifier.

pitr_test=# select * from mytable;
 id | payload |        inserted_at
----+---------+---------------------------
  0 | text_0  | 2025-07-21 09:14:15.78179
  1 | text_1  | 2025-07-21 09:14:15.78179
  2 | text_2  | 2025-07-21 09:14:15.78179
  3 | text_3  | 2025-07-21 09:14:15.78179
  4 | text_4  | 2025-07-21 09:14:15.78179
  5 | text_5  | 2025-07-21 09:14:15.78179
  6 | text_6  | 2025-07-21 09:14:15.78179
  7 | text_7  | 2025-07-21 09:14:15.78179
  8 | text_8  | 2025-07-21 09:14:15.78179
  9 | text_9  | 2025-07-21 09:14:15.78179
 10 | text_10 | 2025-07-21 09:14:15.78179
(11 rows)

Les données insérées à 09:14:15 sont bien présentes, la suppression ayant eu lieu après.

Forcer l’écriture des journaux de transaction.

select pg_switch_wal();
 pg_switch_wal
---------------
 0/100072D0

8. Stopper PostgreSQL localement

9. Redémarrer Patroni sur le primaire choisi

systemctl start patroni

10. Vérifier la promotion

patronictl -c /etc/patroni/config.yml topology
+ Cluster: loxodemo (7427142939826752414) -+----+-----------+
| Member  | Host        | Role   | State   | TL | Lag in MB |
+---------+-------------+--------+---------+----+-----------+
| pgdeb01 | 10.200.0.11 | Leader | running |  5 |           |
+---------+-------------+--------+---------+----+-----------+

11. Redémarrer Patroni sur chaque réplica

systemctl start patroni

patronictl -c /etc/patroni/config.yml topology
+ Cluster: loxodemo (7427142939826752414) ------+----+-----------+
| Member    | Host        | Role    | State     | TL | Lag in MB |
+-----------+-------------+---------+-----------+----+-----------+
| pgdeb01   | 10.200.0.11 | Leader  | running   |  5 |           |
| + pgdeb02 | 10.200.0.12 | Replica | streaming |  5 |         0 |
| + pgdeb03 | 10.200.0.13 | Replica | streaming |  5 |         0 |
+-----------+-------------+---------+-----------+----+-----------+

Méthode 2 : Bootstrap du cluster avec Patroni

Cette méthode est plus lourde, mais parfois nécessaire (ex. : restauration complète ou scriptée).

1. Connectez-vous sur une des machines qui sera le futur primaire.

2. Supprimer ou déplacer le répertoire de données de PostgreSQL

rm -rf /data/postgres/loxodemo

mv /data/postgres/loxodemo /data/postgres/loxodemo_archive

3. Supprimer le cluster dans Etcd

patronictl -c /etc/patroni/config.yml remove loxodemo

Confirmation obligatoire :

Please confirm the cluster name to remove: loxodemo
You are about to remove all information ... please type: "Yes I am aware": Yes I am aware

4. Modifier la configuration de Patroni

Ajoutez à la section bootstrap :

bootstrap:
  method: pgbackrest
  pgbackrest:
    command: '/usr/bin/pgbackrest --stanza=loxodemo --delta restore'
    keep_existing_recovery_conf: false
    no_params: true
    recovery_conf:
      recovery_target_action: promote
      recovery_target_time: "2025-07-21 09:14:16.78179+00"
      restore_command: pgbackrest --stanza=loxodemo archive-get %f %p

5. Redémarrer Patroni sur le futur primaire

systemctl start patroni

Les logs doivent indiquer la séquence de bootstrap :

2025-07-21 12:59:23 INFO: Selected new etcd server http://10.200.0.12:2379
2025-07-21 12:59:23 INFO: No PostgreSQL configuration items changed, nothing to reload.
2025-07-21 12:59:23 INFO: Lock owner: None; I am pgdeb01
2025-07-21 12:59:23 INFO: trying to bootstrap a new cluster
2025-07-21 12:59:23 INFO: Running custom bootstrap script: /usr/bin/pgbackrest --stanza=loxodemo restore
2025-07-21 12:59:24 INFO: Lock owner: None; I am pgdeb01
2025-07-21 12:59:24 INFO: not healthy enough for leader race
2025-07-21 12:59:24 INFO: bootstrap in progress
2025-07-21 12:59:25 INFO: Lock owner: None; I am pgdeb01
2025-07-21 12:59:25 INFO: not healthy enough for leader race
2025-07-21 12:59:25 INFO: bootstrap in progress
2025-07-21 12:59:26 INFO: Lock owner: None; I am pgdeb01

Forcer l’écriture des journaux de transaction et par conséquent l’archivage.

select * from pg_switch_wal();
 pg_switch_wal
---------------
 0/9004A00
(1 row)

6. Redémarrer Patroni sur chaque réplica

systemctl start patroni

Contrôler l’état du cluster:

patronictl -c /etc/patroni/config.yml topology
+ Cluster: loxodemo (7427142939826752414) ------+-----+-----------+
| Member    | Host        | Role    | State     |  TL | Lag in MB |
+-----------+-------------+---------+-----------+-----+-----------+
| pgdeb01   | 10.200.0.11 | Leader  | running   |  10 |           |
| + pgdeb02 | 10.200.0.12 | Replica | streaming |  10 |         0 |
| + pgdeb03 | 10.200.0.13 | Replica | streaming |  10 |         0 |
+-----------+-------------+---------+-----------+-----+-----------+

Quelle méthode choisir ?

Méthode	Avantages	Inconvénients
Manuelle (–delta)	Restauration plus rapide, plus granulaire	Plus de manipulation manuelle
Bootstrap Patroni	Automatisable, plus propre dans certains cas	Plus long, pas de restauration delta

Conclusion

Grâce à pgBackRest et Patroni, il est possible de restaurer un cluster PostgreSQL à un instant précis, que ce soit pour corriger une erreur humaine ou revenir à un état stable après une défaillance. Selon les besoins (rapidité vs réinitialisation complète), l’une ou l’autre des méthodes peut être utilisée efficacement.

PostgreSQL 18

Mon, 29 Sep 2025 10:45:00 +0200

Sortie de PostgreSQL 18

Le PostgreSQL Global Development Group a annoncé le 25 septembre 2025 la publication de PostgreSQL 18, dernière version de la base de données open source de référence.

Vous pouvez retrouver la note de sortie de PostgreSQL 18 sur le site officiel, ainsi que les dossiers de presse, dont celui traduit en français.

Les nouveautés

Plutôt que de passer en revue tous les éléments de la note de sortie, on peut rappeler les nouveautés qu’apporte cette version 18 de PostgreSQL dont la maintenance nous amènera jusqu’en 2030.

La fonctionnalité la plus attendue est la prise en charge des entrées/sorties asynchrones. Cette dernière permet d’améliorer certains types de lecture et des tâches de maintenance comme le vacuum. Le nouveau paramètre io_method permet de configurer la méthode utilisée.
L’introduction des recherches skip scan sur les index B-tree multicolonnes afin d’améliorer les temps d’exécution pour les requêtes qui omettent une condition = sur une ou plusieurs colonnes préfixes de l’index.
La conservation des statistiques utilisées par le planificateur lors des mises à jour majeur avec pg_upgrade.
L’ajout de la fonction uuidv7() pour générer des UUIDs aléatoire ordonnées dans le temps, ou l’ajout de contraintes temporelles ou sur intervalles sur les contraintes PRIMARY KEY, UNIQUE et FOREIGN KEY.
L’ajout des variables OLD et NEW dans les clauses RETURNING pour les ordres de modifications SQL (INSERT, UPDATE, DELETE, and MERGE).
Les colonnes générées virtuelles qui permettent de calculer à la volée les valeurs et ne plus les stocker, et devient le comportement par défaut pour les colonnes générées.
Concernant la réplication logique, l’application des transactions par des flux parallèles par défaut (CREATE SUBSCRIPTION et le paramètre streaming), la suppression des slots de réplication inactifs, la journalisation des conflits en écriture et l’ajout d’un nouveau paramètre --all dans l’utilitaire pg_createsubcriber.
Le support du framework d’authentification OAuth 2.0.

Crédits photo Richard Jacobs.

Blog Loxodata

PostgreSQL 19 bêta 1

PostgreSQL 19 Bêta 1 publiée

Principales fonctionnalités de PostgreSQL 19

Performance

Expérience développeur

Fonctionnalité liées à la sécurité

Supervision et observabilité

Réplication logique et requêtes fédérées

Autres points importants

Fonctionnalités supplémentaires

Tests pour le débogage et la compatibilité

Planning Bêta

Liens

Retour sur le PG Day France 2026

Retour sur les journées du PG Day France 2026

Les conférences

PostgreSQL 18.4 et autres correctifs

Notification de la fin de vie de PostgreSQL 14

Problème de sécurité

Corrections de bogues et améliorations

Mise à jour

Liens

Meetup du 7 avril 2026 PostgreSQL à Toulouse

Meetup UPDATE meetup SET location='Pictarine' WHERE group='TLSPUG';

Retour sur le pgDay Paris 2026

Les conférences

A framework for self-driving databases

From Crisis to Control: Detect and Fix Corruptions

postgresql.org: The hidden parts

Database optimization and reducing global digital pollution

Operational hazards of managing PostgreSQL DBs over 100TB

Creating a “Dungeon Master” with Postgres and MCP

Synchronisation of logical replication slots

Customizing the Wordle Game Experience with PostgreSQL

Postgres Therapy Session: What the Elephant Can Learn from Its Rivals.

Conclusion

PostgreSQL 18.3 et autres correctifs

Corrections de bogues et améliorations

Mise à jour

Liens

PostgreSQL 18.2 et autres correctifs

Problèmes de sécurité

Corrections de bogues et améliorations

Mise à jour

Liens

De retour du FOSDEM PGDay 2026

De retour du FOSDEM PGDay 2026

Zero-Downtime Upgrades: PostgreSQL and OS/glibc at Global Scale

Efficiently approximating/estimating percentiles and histograms

Storage Performance Matters: Benchmarking PostgreSQL on Kubernetes

Lighting talks

Batching in Executor

From Crisis to Control: Detect and Fix Corruptions

Vibe-coding with Postgres: really?

Conclusion :

Retour sur le DevFest Toulouse 2025

Retour sur le DevFest Toulouse 2025

Les conférences

Conclusion

PostgreSQL Conference Europe 2025

Retour sur la PostgreSQL Conference Europe 2025

Community events day

La conférence

Performance

Administration

High availibility

Autres

Conclusion

Plusieurs évènements sur Toulouse à ne pas rater en Novembre

Éviter les chevauchements temporels

Et en pratique

Avec deux dates

Plage de dates et contraintes d’exclusion

Plage de dates et la clause WITHOUT OVERLAPS

Performance et taille sur le disque

Performance en insertion

Volume des index

Performance de recherche

Conclusion

Meetup `UPDATE meetup SET location='Pictarine' WHERE group='TLSPUG';`

Meetup `pg_ctl restart -D Toulouse`