veilletech.fr
2 nov. Feed du jour
#03 POSTGRES Article

Postgres 19 retardé : les LLM trouvent trop de bugs

Quarante ans de bugs viennent d'être rendus visibles. Ils ne se corrigeront pas seuls.

Robert Haas, développeur de PostgreSQL, explique pourquoi la version 19 sortira tard : les bugs trouvés grâce aux LLM ont fait bondir les rétroportages et absorbé le temps de relecture. Trois grosses fonctionnalités ont été retirées en fin de bêta. Plans de migration et feuilles de route sont à revoir.

2 min de lectureintermédiairevidéo 1:21
Partager
Sommaire5 sections
  1. Ce qui se passe
  2. Les chiffres
  3. L'explication avancée
  4. Ce que ça change
  5. À retenir

Ce qui se passe

Depuis une dizaine d'années, une version majeure de PostgreSQL sort entre la mi-septembre et la mi-octobre. PostgreSQL 19 ne tiendra pas ce rythme : Robert Haas la voit très probablement arriver en novembre, sans exclure un report supplémentaire. À la mi-octobre, heise évoquait une sortie visée le 19 novembre.

Surtout, trois fonctionnalités importantes ont été retirées entre le 27 août et le 15 septembre, un moment inhabituellement tardif :

Les chiffres

Commits entre le 8 avril, date du gel des fonctionnalités, et le 25 septembre :

Branche 2025 2026 Hausse
Branche stable en préparation (18, puis 19) 724 1 169 + 61 %
Branche stable précédente (17, puis 18) 248 433 + 75 %
master, tous commits 1 037 1 443 + 39 %

En retirant de master ce qui a aussi été porté sur la branche en préparation, le volume baisse légèrement d'une année à l'autre. La hausse vient donc des corrections, pas de nouveaux développements.

L'explication avancée

Pour Haas, les LLM permettent à beaucoup plus de monde de trouver des bugs dans un code dont l'historique Git remonte à plus de trente ans. Corriger est aussi devenu plus facile, mais pas autant : un correctif rédigé par un modèle n'est pas toujours juste, et il doit passer par un humain. Ce temps manque ensuite pour décider quoi retirer de la version à venir.

Cela reste son analyse. Il admet que des erreurs plus nombreuses des committers peuvent peser, tout en estimant que personne dans le projet n'y voit la cause principale. Le décompte ne distingue pas les bugs selon leur origine.

Il ne s'inquiète pas du retard lui-même, mais du long terme : comment rattraper quarante ans de bugs tout en continuant à innover ? Il dit ne pas avoir la réponse.

Ce que ça change

  1. Calendrier : repoussez toute migration calée sur une sortie à l'automne.
  2. Feuille de route : si un projet comptait sur l'une des trois fonctionnalités retirées, cherchez une autre voie. Rien dans ce billet ne promet leur retour dans une version précise.
  3. Mises à jour mineures : avec autant de rétroportages, attendez-vous à des notes de version plus longues. Lisez-les et testez avant de déployer. C'est notre déduction, pas une annonce du projet.

À retenir

Haas juge que chaque fonctionnalité sera désormais examinée par des modèles, et parfois en quelques heures. Si un projet aussi rigoureux en sort ralenti, le vôtre peut anticiper la même pression sur ses relectures.

Source : Robert Haas, billet paru d'abord chez Neon. Source en anglais.