Umělá inteligence

Robert Haas přičítá odklad PostgreSQL 19 chybám nalezeným jazykovými modely

PostgreSQL 19 dostane 12. listopadu druhého kandidáta na vydání a ostrá verze má vyjít 19. listopadu, nejpozději za posledních deset let. Vývojář projektu Robert Haas spočítal, že do stabilních větví letos šlo o 60 až 75 % víc oprav než loni. Připisuje to hlášením chyb, které lidé našli pomocí jazykových modelů.

2. listopadu 2026 · 0 zhlédnutí

Dva dobrovolníci v tričkách s logem PostgreSQL sedí u stolu s notebooky na stánku konference — Stánek francouzské komunity PostgreSQL na Paris Open Source Summit 2015. Foto: Oliver H, Wikimedia Commons (CC BY-SA 3.0)

Nový termín oznámil tým pro vydání 10. října v konferenci pgsql-hackers. Jonathan Katz v e-mailu napsal, že ostrá verze PostgreSQL 19 vyjde 19. listopadu, týden po plánovaném opravném vydání starších větví. Důvodem je podle něj množství oprav, které se mezitím dostaly do stabilních větví. Tým je chce mít ve verzi 19 dřív, než ji prohlásí za hotovou. První kandidát na vydání vyšel podle plánu 15. října, druhý přijde 12. listopadu.

Proč je oprav tolik, rozebral 30. října Robert Haas, dlouholetý vývojář PostgreSQL s právem zapisovat do repozitáře. Jeho příspěvek se jmenuje „Postgres 19 is late, and it's AI's fault“ a vyšel nejdřív na blogu firmy Neon. Vysvětlení je prosté: velký a starý kód obsahuje spoustu chyb odjakživa, jen se teď díky jazykovým modelům hledají mnohem snáz. Opravovat je se tolik zrychlit nepodařilo.

Nejpozdější vydání za deset let

Hlavní verze PostgreSQL podle Haase za poslední desetiletí vycházely nejdřív v polovině září a nejpozději v polovině října. Tabulka verzí na webu projektu to potvrzuje s jednou výjimkou: verze 11 vyšla 18. října 2018. Loňská verze 18 měla prvního kandidáta 4. září a ostré vydání o tři týdny později.

Verze	Ostré vydání
14	30. září 2021
15	13. října 2022
16	14. září 2023
17	26. září 2024
18	25. září 2025
19	19. listopadu 2026 (plán)

Na 12. listopadu, kdy má vyjít druhý kandidát, připadá i poslední opravné vydání řady 14, které tím končí podpora. Stránka s plánem vývoje ke 2. listopadu pořád uvádí, že verze 19 je plánovaná na říjen.

O šedesát procent víc oprav

Haas porovnal stejné období dvou let, od zmrazení funkcí 8. dubna do 25. září. Do hlavní větve šlo letos víc commitů, nárůst ale nese hlavně stabilní větev připravované verze, kam se přenášejí opravy. Commitů jen do hlavní větve bylo podle něj letos dokonce o něco méně než loni.

Větev	2025	2026	Změna
hlavní větev (master)	1 037	1 443	+39 %
stabilní větev připravované verze (18, resp. 19)	724	1 169	+61 %
stabilní větev předchozí verze (17, resp. 18)	248	433	+75 %

Poslední řádek Haas zdůrazňuje. Oprava, která se musí přenést i do loni vydané verze, míří na chybu v kódu, který už běží u uživatelů. „Obrovské množství lidí na internetu teď hlásí chyby v PostgreSQL, které našli pomocí jazykových modelů,“ píše. Sami jsme commity spočítali přes zrcadlo repozitáře na GitHubu se stejným rozsahem dat. Vyšlo nám 733 a 1 178 commitů ve stabilní větvi připravované verze a 248 a 435 v té předchozí. Čísla se od Haasových liší o jednotky, poměr zůstává: o 61 a o 75 % víc.

Velké novinky se vracely až koncem léta

Druhý důsledek je podle Haase méně vidět. Čas, který by vývojáři věnovali kontrole novinek verze 19, spotřebovaly bezpečnostní opravy a chyby ve starších větvích. Problémy nových funkcí se tak ukázaly pozdě. Ve větvi REL_19_STABLE leží tyhle reverty:

Funkce	Vrácena z verze 19
`ALTER TABLE … MERGE/SPLIT PARTITION`	27. srpna
dotazy nad grafy SQL/PGQ	7. září
`pg_get_role_ddl()`, `pg_get_tablespace_ddl()` a `pg_get_database_ddl()`	13. září
`UPDATE/DELETE FOR PORTION OF`	15. září
zapínání a vypínání kontrolních součtů dat za běhu	16. září

Nejvíc to mění obraz verze u SQL/PGQ. Článek o druhé betě ho v červenci popsal jako největší novinku verze 19, do ostrého vydání se ale nedostane. V kódu naopak zůstal příkaz REPACK včetně souběžné varianty, rady pro plánovač pg_plan_advice a paralelní autovacuum. Oznámení prvního kandidáta u všech tří vyjmenovává další opravy.

Pořadí nejrizikovějších záplat sestavil Claude

O tom, co vrátit, se rozhodovalo i s pomocí jazykového modelu. Haas 25. srpna poslal do pgsql-hackers zprávu s předmětem „scary patch contest“. Požádal v ní Clauda, aby podle počtu a druhu chyb opravených po zmrazení funkcí určil nejrizikovější záplaty verze 19. Výsledek zveřejnil s poznámkou, že pár obzvlášť jízlivých komentářů modelu vypustil.

Na seznamu bylo šest položek. REPACK měl 28 oprav, mezi nimi i opravu ztráty dat, zapínání kontrolních součtů za běhu asi 25 a FOR PORTION OF 17, z toho tři bezpečnostní. Tři ze šesti položek se pak z verze 19 vrátily celé. REPACK zůstal, jeho souběžná varianta ale smí v celém clusteru běžet jen v jednom procesu.

Christophe Pettus, který průběh cyklu v polovině září rozebral na svém blogu The Build, cituje z téhož vlákna Melanie Plageman z týmu pro vydání. Ta se ptala, jestli to, jak snadno se dnes funkce s pomocí jazykových modelů prověřují, neznamená hlavně to, že se chyby najdou dřív než v minulých letech.

Opravu navrhne model, schválit ji musí člověk

Modely podle Haase umějí opravu i navrhnout. Taková oprava ale není vždy správná ani v souladu se zvyklostmi projektu, takže ji dál musí posoudit a zapsat člověk – a lidé, jak píše, „mezi lety 2025 a 2026 nijak nezmoudřeli“. Samotný odklad o pár týdnů ho netrápí, protože podle něj vychází z péče o kvalitu. Víc ho znepokojuje výhled: když modely najdou čtyřicet let chyb, které lidé neviděli, není jasné, jak to projekt dožene a kdy bude mít čas na nové funkce.

Haas mluví o skutečných chybách, které se opravují, ne o bezcenných hlášeních. V tom se liší od stížností na strojově generovaný šum, které zazněly v průzkumu Linux Foundation mezi správci projektů. Kód PostgreSQL přitom označuje za jeden z nejčistších, na jakých kdy pracoval. Kdyby byl horší, našly by v něm modely chyb podle něj ještě víc.

Zdroje

Umělá inteligence

Open source jazykové modely databáze PostgreSQL

Generováno AI