Skip to content

PostgreSQL 19 : la version finale attendue le 29 octobre

PostgreSQL 19 : release candidate le 15 octobre, version finale visée le 29. REPACK, autovacuum revu et fonctions retirées avant la sortie.

Publié le 3 min de lecture
PostgreSQL 19 : la version finale attendue le 29 octobre

La sortie de PostgreSQL 19 a désormais un calendrier. Dans un message adressé le 28 septembre à la liste des développeurs, l'équipe de publication fixe la première release candidate (RC1) au jeudi 15 octobre 2026 et la version finale au jeudi 29 octobre, sauf problème important détecté entre-temps. La quatrième bêta, publiée le 24 septembre, a par ailleurs allégé la liste des nouveautés en retirant plusieurs fonctions jugées pas assez mûres.

Un calendrier calé sur la mise à jour de novembre

Le choix du 29 octobre n'est pas anodin. Selon l'annonce, il laisse quelques semaines de corrections avant la mise à jour mineure de novembre, la façon dont le projet cherche habituellement à positionner ses versions majeures. L'annonce de la bêta 4 évoquait une RC « début octobre » : le calendrier a donc glissé d'une quinzaine de jours, sans remettre en cause une sortie en octobre.

Des fonctions retirées avant la sortie

La bêta 4 a surtout fait le ménage. Le PostgreSQL Global Development Group explique que la fiabilité passe avant tout et que le projet tient à un calendrier de publication prévisible. Plusieurs fonctions prévues ont donc été retirées, avec la possibilité de revenir dans une version majeure ultérieure :

  • le support de SQL/PGQ, les requêtes sur graphes de propriétés ;
  • l'activation et la désactivation en ligne des sommes de contrôle des données ;
  • les mises à jour et suppressions temporelles via la clause FOR PORTION OF ;
  • les commandes ALTER TABLE ... MERGE PARTITIONS et SPLIT PARTITIONS ;
  • les fonctions pg_get_role_ddl(), pg_get_tablespace_ddl() et pg_get_database_ddl().

Ce qui reste au programme

Les notes de version conservent plusieurs nouveautés notables. La commande REPACK récupère l'espace disque et réorganise les tables, en reprenant les rôles de VACUUM FULL et CLUSTER, qui restent disponibles. Son option CONCURRENTLY permet l'opération sans bloquer lectures et écritures.

L'autovacuum peut désormais traiter les index d'une table avec des processus parallèles, et un nouveau système de score décide quelles tables nettoyer ou analyser en priorité. La réplication logique transmet les valeurs des séquences. Une commande WAIT permet d'attendre qu'un serveur secondaire ait rejoué les modifications jusqu'à un point donné, utile pour lire ses propres écritures sur un réplica. Enfin, l'extension pg_plan_advice sert à stabiliser les choix du planificateur de requêtes. Côté performances, le projet cite des vérifications de clés étrangères plus rapides et un ajustement automatique du nombre de processus d'entrée-sortie, sans donner de chiffres.

Les points à vérifier avant de migrer

Comme toute version majeure, PostgreSQL 19 impose pg_upgrade ou un export suivi d'une restauration. Les notes listent aussi des incompatibilités à anticiper :

  • standard_conforming_strings est toujours activé : les sauvegardes produites par un ancien pg_dump avec ce paramètre désactivé ne se rechargent pas ;
  • la compilation JIT est désactivée par défaut, à réactiver pour les charges analytiques lourdes ;
  • la valeur par défaut de max_locks_per_transaction passe de 64 à 128, et le calcul des verrous change ;
  • l'authentification RADIUS est supprimée ;
  • pg_upgrade refuse les clusters contenant certains index btree_gist sur les types inet et cidr.

Le projet invite d'ici là à tester la bêta sur ses propres charges et à signaler les anomalies. Pour les équipes qui déploient PostgreSQL en conteneurs Docker, la RC du 15 octobre offre une fenêtre pratique pour valider les images et les scripts de migration avant la version finale.

Articles liés

Java 27 généralise le ramasse-miettes G1, active les en-têtes d'objets compacts et ajoute un échange de clés TLS post-quantique. Le point sur ses 9 JEP.
Python 3.15 arrive avec imports paresseux, frozendict, UTF-8 par défaut et un JIT amélioré. Ce qu'il faut tester avant de migrer.
Node.js 26 devient LTS le 28 octobre 2026, dernière version sous l'ancien calendrier. Dès Node.js 27, une seule version majeure par an.