PostgreSQL 19 pārcelts uz novembri: LLM koda pārskatīšana atrada kļūdas ātrāk nekā izstrādātāji spēja labot

PostgreSQL 19 iznāks 19. novembrī. Sākotnēji izlaidums bija plānots septembra beigās. Aizkavēšanās iemesls ir neparasts: LLM rīku palīdzēta koda pārskatīšana vienā izlaiduma ciklā atklāja ap 40 defektu ziņojumu, ko izstrādātāju komanda nespēja apstrādāt līdz plānotajam termiņam. Rezultātā tika atsauktas astoņas līdz desmit funkcijas, kas parasti būtu nonākušas jaunajā versijā.

PostgreSQL Global Development Group 15. oktobrī publicēja pirmo laidiena kandidātu (RC1). Otrais kandidāts (RC2) plānots 12. novembrī. Ja netiks atrasta kritiska kļūda, vispārīgā pieejamība (GA) iestāsies tieši nedēļu vēlāk.

Atsaukto funkciju saraksts

Peter Eisentraut, EDB komitētājs, ir viens no pieredzējušākajiem PostgreSQL izstrādātājiem. 9. oktobrī viņš aprakstīja situāciju pgEdge emuārā. Parasti vienā izlaiduma ciklā PostgreSQL atsauc vienu funkciju. Šoreiz skaits sasniedza astoņas līdz desmit.

Lielākā atsauktā funkcija bija SQL/PGQ jeb property graph queries. Tā ļautu lietotājiem rakstīt grafu vaicājumus tieši SQL valodā, izmantojot ISO standarta sintaksi. PostgreSQL lietotāji varētu veidot grafu modeļus pāri esošajām relāciju tabulām bez ārējiem paplašinājumiem, piemēram, Apache AGE. Atsaukšana notika 7. septembrī ar komitu 2b9e1aff4d, kas atraisīja 47 iepriekšējos komitus gan stabilajā zarā REL_19_STABLE, gan galvenajā (master). Kods nav zudis. Tas pārvietots uz PostgreSQL 20 izstrādes zaru.

Starp citām atsauktajām funkcijām ir UPDATE/DELETE FOR PORTION OF, kas paredzēta temporālu tabulu daļējai modificēšanai. Tāpat atsaukta ALTER TABLE MERGE PARTITION/SPLIT PARTITION, ar kuru varētu apvienot vai sadalīt tabulu nodalījumus bez pilnas pārbūves. Trešā lielā atsaukšana ir GROUP BY ALL, kas automātiski grupētu rezultātus pēc visām neagregētajām SELECT kolonnām. Šāda sintakse jau darbojas DuckDB, ClickHouse un vairākās citās analītiskajās datubāzēs. GROUP BY ALL atsaukšanas komitā tiešā tekstā teikts: “We will revert and try again in v20.”

Četrdesmit ziņojumu, trīs rindiņas katram labojumam

Eisentraut savā ierakstā skaidroja aizkavēšanās mehānismu. Kopienas dalībnieki pārskatīšanā izmantoja LLM rīkus, kas atrada garu sarakstu ar malas gadījumu kļūdām (edge-case bugs). Katra atsevišķā kļūda bija neliela. Labojums parasti prasīja aptuveni trīs koda rindiņas. Tomēr katrs ziņojums nesa sev līdzi fiksētu darba apjomu: problēmas izpēti, testa gadījuma uzrakstīšanu, komitu, cita izstrādātāja pārskatīšanu. Pie 40 ziņojumiem šīs fiksētās izmaksas saskaitījās līdz apjomam, ko pieejamie cilvēki nespēja paveikt sākotnēji noteiktajā laikā.

“LLM palīdzēta pārskatīšana var atklāt šādas problēmas daudz ātrāk, atstājot izstrādātājiem sarakstu ar apmēram četrdesmit defektu ziņojumiem. Pat ja katrs labojums ir trīs rindiņas, fiksētās izmaksas nozīmē, ka laika pietrūkst.” — Peter Eisentraut, pgEdge emuārs

Eisentraut uzsvēra, ka šī situācija nav saistīta ar “vibe coding” praksi, kurā izstrādātāji liek LLM ģenerēt visu kodu. Atsauktais kods bija rakstīts gadus pirms LLM rīki kļuva lietojami izstrādē. Notika cita lieta: kvalitātes pārskatīšanas latiņa pacēlās pēc tam, kad kods jau bija iekļauts repozitorijā. LLM rīki atrada problēmas, ko cilvēku pārskatītāji iepriekš nebija pamanījuši.

Drošības labojumi aizņēma vecākos pārskatītājus

Vēl viens faktors pasliktināja situāciju. No aprīļa līdz augustam vecākie PostgreSQL pārskatītāji bija aizņemti ar drošības labojumiem. Tieši tajā periodā, kad LLM rīki sāka ģenerēt defektu ziņojumus, cilvēki ar pietiekamu pieredzi nebija pieejami to triāžai. Projekts saskārās ar situāciju, kurā ienākošo ziņojumu plūsma pieauga, bet pieejamais darbaspēks samazinājās.

RC1 paziņojumā laidiena komanda paskaidroja RC2 grafiku. 12. novembra mazais atjauninājums nesīs lielu labojumu porciju vecākajām PostgreSQL versijām. Komanda nolēma izlaist RC2 tajā pašā datumā, lai abi atjauninājumu veidi tiktu testēti kopā.

Ātrāka kļūdu atrašana pati par sevi nepalīdz

PostgreSQL pieredze parāda praktisku problēmu, ar kuru saskarsies citi atvērtā koda projekti. LLM rīki spēj atrast kļūdas, ko cilvēka acis palaiž garām. Bet kļūdu labošana joprojām prasa cilvēku darbu: izpēti, diskusiju par labojuma pieeju, koda rakstīšanu, testēšanu, pārskatīšanu. Ja kļūdu atklāšanas ātrums pārsniedz labošanas ātrumu, projekts atpaliek no grafika pat tad, ja kods objektīvi kļūst labāks.

Kopienas diskusijās viedokļi dalās. Daži dalībnieki argumentē, ka LLM pārskatīšana atrod reālas kļūdas, kuras citādi netiktu labotas līdz pēclaidiena versijām. Citi norāda, ka daļa LLM atklāto defektu ir viltus pozitīvi, kas tērē laiku bez reāla ieguvuma. PostgreSQL gadījumā Eisentraut nešķiro starp abām kategorijām. Viņš vienkārši konstatē, ka ziņojumu bija pārāk daudz.

Par atsaukto funkciju likteni Eisentraut ir optimistisks. Viņš sagaida, ka lielākā daļa atgriezīsies PostgreSQL 20 izstrādes ciklā. SQL/PGQ, GROUP BY ALL un pārējās funkcijas jau ir rindā uz nākamo versiju. Dažas viņš raksturo kā “80 % gatavas”.

PostgreSQL 19 grafiks

RC1 iznāca 15. oktobrī. RC2 plānots 12. novembrī. Vispārīgā pieejamība (GA) gaidāma 19. novembrī. SQL/PGQ, GROUP BY ALL, UPDATE/DELETE FOR PORTION OF šajā versijā nebūs. 12. novembra mazais laidiens nesīs drošības labojumus arī vecākajām atbalstītajām PostgreSQL versijām, sākot no 14. versijas.

Avoti

• PostgreSQL 19 RC 1 paziņojums (postgresql.org)
• Atjaunināti PostgreSQL RC/GA datumi (postgresql.org vēstkopas)
• Looking Forward to Postgres 19: Epilogue (pgEdge emuārs)
• PostgreSQL 19 Delayed After AI Review Finds Bugs (technology.org)