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.
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 PARTITIONSetSPLIT PARTITIONS; - les fonctions
pg_get_role_ddl(),pg_get_tablespace_ddl()etpg_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_stringsest toujours activé : les sauvegardes produites par un ancienpg_dumpavec 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_transactionpasse de 64 à 128, et le calcul des verrous change ; - l'authentification RADIUS est supprimée ;
pg_upgraderefuse les clusters contenant certains indexbtree_gistsur les typesinetetcidr.
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.