Peter Eisentraut on kehittänyt PostgreSQL-tietokantaa vuosia. Lokakuun 9. päivänä hän julkaisi blogissaan kirjoituksen, jonka otsikko on vapaasti suomennettuna ”Perumiset jatkuvat, kunnes työmoraali paranee”. Siinä hän selittää, miksi PostgreSQL 19 ilmestyy myöhässä ja ohuempana kuin piti.
Syy on yllättävä. Kielimallien avustama koodikatselmointi löytää vikoja niin nopeasti, etteivät kehittäjät ehdi korjata kaikkia ennen julkaisua.
PostgreSQL on avoimen lähdekoodin tietokanta, joka pyörii lukemattomien verkkopalvelujen, sovellusten ja myös julkisen sektorin järjestelmien taustalla, joten moni suomalainen käyttää sitä päivittäin tietämättään. Uusi pääversio julkaistaan kerran vuodessa.
Kahdeksasta kymmeneen ominaisuutta pois
The Registerin mukaan PostgreSQL 19:n piti alun perin ilmestyä syyskuun lopussa tai lokakuun alussa. Projekti julkaisi 15. lokakuuta ensimmäisen julkaisuehdokkaan, ja sen tiedotteen mukaan lopullinen versio on suunniteltu julkaistavaksi 19. marraskuuta, ellei uusia ongelmia ilmene.
Eisentrautin mukaan beetavaiheen alettua versiosta on peruttu ”noin 8–10 merkittävää ominaisuutta, riippuen siitä miten lasketaan”. Tavallisesti perumisia on yksi kehityskierrosta kohden. Hänen arvionsa mukaan PostgreSQL 19:ssä on nyt noin puolet niistä suurista uudistuksista, joita hän vielä muutama kuukausi sitten odotti.
Eisentraut on PostgreSQL-tukea ja konsultointia tarjoavan EDB:n varapääjohtaja. Hän kuuluu niihin kehittäjiin, joilla on oikeus viedä muutoksia projektin koodiin.
Neljäkymmentä vikailmoitusta, kolme riviä kukin
Eisentraut kuvaa tyypillistä tilannetta näin: kehittäjän ominaisuus on valmis ja hyväksytty, mutta sitten kielimalliavusteinen katselmointi käy koodin läpi. Edessä on hänen sanoin ”lista, jossa on jotain neljäkymmentä vikailmoitusta”. Keskimäärin kunkin korjaus vaatii hänen arvionsa mukaan vain noin kolme riviä koodia.
Ongelma on määrä. The Registerille hän sanoi, että ”jokaisen käsittelyyn liittyy kiinteä työmäärä, ja sitten aika loppuu”.
“Kielimalliavusteisella koodikatselmoinnilla tällaiset asiat löytyvät paljon nopeammin.”
Osa löydöistä oli pieniä reunatapauksia, jotka olisivat ennen paljastuneet ehkä vasta vuosia julkaisun jälkeen. Osassa perutuista ominaisuuksista oli kuitenkin The Registerin mukaan niin syviä rakenteellisia vikoja, ettei niitä olisi saatu nopeasti kuntoon beetavaiheessa.
Eisentrautin mukaan kahden kuukauden lisäaika olisi riittänyt jäljellä olevien ongelmien korjaamiseen. Yhteisö päätti kuitenkin mieluummin pysytellä aikataulussa kuin lykätä julkaisua saadakseen lisää korjauksia mukaan.
Tilannetta hankaloitti sekin, että monet kokeneet kehittäjät olivat huhtikuusta alkaen kiinni haavoittuvuuksien selvittelyssä. Eisentraut kutsuu ilmiötä nimellä ”Vulnpocalypse”. Samassa kuussa alkoi version 19 ominaisuusjäädytys.
Laatuvaatimus nousi jälkikäteen
Eisentraut korostaa, ettei kyse ole niin sanotusta vibe-koodauksesta eli koodin tuottamisesta kielimallilla ilman tarkkaa ymmärrystä. ”Tämä koodi kirjoitettiin hyvissä ajoin ennen kuin se oli edes mahdollista”, hän kirjoittaa englanninkielisessä blogissaan.
Ihmiset siis kirjoittivat koodin, mutta mittapuu muuttui kesken kaiken. ”Tosiasiallinen laatuvaatimus on noussut sen jälkeen, kun ominaisuus kirjoitettiin ja vietiin koodiin”, Eisentraut sanoi The Registerille.
PostgreSQL:n rakenne tekee asiasta erityisen hankalan. ”Sanon mielelläni, että PostgreSQL:ssä ’kaikki toimii kaiken kanssa’”, Eisentraut kirjoittaa. Jokaisen uuden ominaisuuden pitää toimia yhteen kaikkien vanhojen kanssa, ja juuri tällaisia yhdistelmiä kielimallin avustama fuzz-testaus eli ohjelman koettelu satunnaisilla syötteillä löytää nopeasti.
Näkyvin peruttu ominaisuus on SQL/PGQ, vuonna 2023 SQL-standardiin lisätty kyselysyntaksi, jolla haetaan solmujen ja niitä yhdistävien suhteiden muodostamia verkostoja. Pitkäaikainen kehittäjä Tom Lane varoitti projektin postituslistalla englanniksi: ”Tässä vaiheessa lyön vaikka illallisesta vetoa, että jos julkaisemme sen v19:ssä, julkaisun jälkeen löytyy bugeja, joita ei voi korjata ennen v20:tä.”
