PostgreSQL 19 kommt ohne rund zehn seiner Neuerungen

Ein Ranking, bestellt bei Claude

Am 25. August schickt Robert Haas eine Nachricht mit dem Titel „scary patch contest“ an die Entwicklerliste von PostgreSQL, der freien Datenbank, die in den 1980er-Jahren in Berkeley entstand. Haas ist einer der Committer, also einer derjenigen, die Code ins Projekt übernehmen dürfen. Er hat Claude gebeten, die Neuerungen der Version 19 zu benennen, die am meisten Sorge machen, gemessen an Zahl und Art der Bugs, die seit dem Feature Freeze behoben wurden. Er veröffentlicht die Rangliste und merkt an, einige besonders bissige Bemerkungen der Maschine gestrichen zu haben.

Sechs Kandidaten. Am häufigsten korrigiert wurde REPACK, ein Wartungsbefehl, mit 28 Fixes. Die im laufenden Betrieb aktivierbaren Prüfsummen kommen auf rund 25, die Graphabfragen auf 17. Haas entscheidet nichts: Er fragt, ob einzelne vor der Veröffentlichung aus der Version herausgenommen werden sollten.

Am selben Tag erklärt Tom Lane, ebenfalls Committer, er wette ein Abendessen: Kämen die Graphabfragen in die 19, enthielten sie Bugs, die sich vor der 20 nicht mehr beheben ließen. Sein Argument hat mit KI nichts zu tun. Noch diskutierte Korrekturen verlangten Eingriffe in den internen Katalog der Datenbank.

Rund zehn Neuerungen zurückgeschickt

Am 7. September werden die Graphabfragen entfernt. Sie wurden 2023 in den SQL-Standard aufgenommen und dienen dazu, Beziehungen zu durchlaufen, etwa ein Freundesnetz oder eine Lieferkette. Der Rückbau macht 47 Änderungen rückgängig: die ursprüngliche Funktion und 46 spätere Nachbesserungen. Unterzeichnet hat Peter Eisentraut, einer ihrer beiden Autoren.

Sie ist nicht allein. In einem Blogeintrag vom 9. Oktober zählt Eisentraut etwa 8 bis 10 wesentliche Funktionen, die aus der 19 entfernt wurden, „je nach Zählweise“, manche sehr spät in der Beta. Üblich sei vielleicht eine pro Zyklus. In der öffentlichen Projekthistorie finden sich unter anderem GROUP BY ALL, eine Abkürzung für Gruppierungen (entfernt am 17. Juli), das Zusammenführen und Aufteilen von Partitionen (27. August) und Updates auf einem Teilzeitraum (15. September).

Auch der Zeitplan ist verrutscht. Am 28. September kündigte das Release-Team die Endversion für den 29. Oktober an. Am 10. Oktober schiebt es sie auf den 19. November. Das ist ein geplanter Termin, der gilt, sofern bis dahin kein Problem entdeckt wird, heißt es in der Ankündigung des ersten Release Candidate vom 15. Oktober.

Die Versionen 16, 17 und 18 erschienen alle im September. Seit 2016 kam keine Hauptversion nach dem 18. Oktober heraus.

Die Latte wurde nach der Abgabe höher gelegt

Warum so viele Streichungen? Eisentraut nennt mehrere Ursachen, vermutlich in Kombination und je Funktion unterschiedlich. Er betont, dass es nur seine Meinung ist. Die erste Erklärung ist ungeschönt: Vielleicht war der Code schlicht nicht gut genug.

Die, die in der Presse hängen blieb, ist eine andere. Von groben Architekturmängeln abgesehen beschreibt er eine lange Schleppe eher harmloser Probleme, Randfälle, die man früher über fünf Jahre hinweg nach und nach behoben hätte. Mit LLM-gestütztem Review tauchen sie auf einmal auf. Dann kann man, schreibt er, vor einer Liste von etwa vierzig Fehlerberichten stehen. Selbst wenn jeder nur drei Zeilen Korrektur braucht, verursacht jeder feste Kosten, und die Zeit wird knapp.

Daher sein Bild: Die Qualitätslatte sei nach dem Schreiben des Codes höher gelegt worden. Das ist, als würde man bei einer Klausur den Bewertungsschlüssel ändern, nachdem die Arbeiten abgegeben sind. Die meisten gestrichenen Funktionen seien vor langer Zeit geschrieben worden, als LLM-Review noch lange nicht so nützlich war.

Mit KI gegengelesen, nicht von ihr geschrieben

Der Unterschied zählt. Eisentraut weist „Vibe Coding“ zurück, also Code, der im Dialog mit einer KI am Fließband entsteht, aber vorsichtig: zum größten Teil, soweit er das beurteilen kann, komme die Lage nicht daher, denn der Code entstand lange bevor das möglich war. Daniel Gustafsson, ein weiterer Committer, sagte schon Ende August, die meisten großen Neuerungen der 19 seien geschrieben, begutachtet und getestet worden, bevor KI-Werkzeuge verfügbar oder auch nur annähernd so gut wie heute waren.

Im Thread von Haas sprechen die anderen von Eindrücken, nicht von Messungen. Nathan Bossart hat das Gefühl, mit LLMs finde man mehr. Richard Guo hatte erwartet, dass KI-Hilfe die Neuerungen zum Feature Freeze stabiler macht, und stellt fest, dass dies offenbar nicht der Fall ist. Amit Kapila sieht langfristig einen Stabilitätsgewinn, erkauft mit kurzfristig mehr Korrekturen.

Eisentraut nennt ein Beispiel für das, was kein Mensch von Hand testet: eine Abfrage auf eine Domain über einem zusammengesetzten Typ, in einer abgetrennten und mit anderer Spaltenreihenfolge wieder angehängten Partition, aufgerufen aus einem Trigger. Niemand könne solche Fälle aufzählen, schreibt er. LLM-gestütztes Fuzzing, das den Code mit generierten Eingaben beschießt, kann dort sehr schnell Probleme finden.

Ein Orakel ist das Werkzeug trotzdem nicht. Paul Jungwirth, Autor der Updates auf Zeiträumen, berichtet, er habe Claude um einen Plan für Kreuztests gebeten. Claude schrieb Tests, ohne einen einzigen neuen Bug zu finden. Andere haben seither zwei gefunden.

Für die Verschiebung gibt es einen anderen Grund

Bleibt die Terminverschiebung, die The Register auf KI-Reviewer zurückführt. Die offizielle Nachricht vom 10. Oktober nennt einen anderen Grund: die Menge an Korrekturen, die in die bereits ausgelieferten Versionen eingeflossen sind. Das Team will sie vor dem finalen Release in einen zweiten Release Candidate am 12. November aufnehmen, dem Tag des vierteljährlichen Updates. Die Streichungen sollten gerade helfen, den Termin zu halten: Statt zu verschieben, um zu reparieren, habe die Community lieber am Termin festgehalten, schreibt Eisentraut.

Ein Faden verbindet beides dennoch. Von April bis August seien viele erfahrene Entwickler damit beschäftigt gewesen, Sicherheitslücken zu schließen, berichtet er, was das übliche Review der Beta verringert habe. Er nennt diese Phase die „Vulnpocalypse“. Im Juni bezeichnete das Wort auf der Sicherheitsliste oss-security die Welle von KI-gefundenen Lücken, die man heranrollen sah.

Die Sicherheitsseite von PostgreSQL verzeichnet 44 Lücken mit Datum 2026, davon 28 im August behoben, gegenüber je 7 in jedem der drei Vorjahre. Sie sagt nicht, wer sie gefunden hat.

Was die 19 behält

Die Version behält REPACK CONCURRENTLY, das eine Tabelle umorganisiert, ohne sie zu sperren, und Hinweise, mit denen sich der Ausführungsplan von Abfragen lenken lässt. Sie werde sehr robust sein, verspricht Eisentraut, nach all dieser zusätzlichen Prüfung. Die 20, von der er vor einigen Monaten sagte, sie könnte gar keine Neuerungen enthalten, erbt schon jetzt zu 80 Prozent fertige Funktionen.

Beim Linux-Kernel erklärt sich inzwischen jeder zehnte Patch als KI-unterstützt, vor allem bei Stammentwicklern, die reparieren. Bei PostgreSQL findet die Maschine bei den Stammentwicklern, was diese übersehen hatten, und laut Eisentraut wird der Engpass die Zeit der Menschen, die reparieren müssen.

Eisentraut geht davon aus, dass sich die Lage in den nächsten Zyklen von selbst einpendeln dürfte. Unter einer Bedingung, die er selbst nennt: dass LLM-Review nicht weiter im heutigen Tempo besser wird.