PostgreSQL 19 verschiebt sich: KI-Prüfung bringt Fehler ans Licht

Dieser Artikel wurde bereits 6x gelesen...

Die Veröffentlichung von PostgreSQL 19 wird nach hinten verschoben: Statt am 29. Oktober soll die neue Hauptversion nun am 19. November 2026 erscheinen. Zusätzlich ist für den 12. November ein weiterer Release Candidate (RC2) vorgesehen. Hintergrund sind zahlreiche jüngst eingearbeitete Korrekturen, die vor der endgültigen Freigabe noch von der Community geprüft werden sollen. Zugleich wurden nach Beginn der Beta-Phase mehrere wichtige Funktionen aus dem geplanten Umfang entfernt. Ein Bericht von InfoQ sieht einen wesentlichen Faktor in leistungsfähiger KI-gestützter Codeprüfung und Fuzz-Testing – allerdings nicht als alleinige Ursache.

Warum die Veröffentlichung später kommt

Die zusätzliche Prüfzeit soll sicherstellen, dass eine größere Zahl jüngst angesammelter Änderungen ausreichend validiert wird. Der erste Release Candidate (RC1) erschien laut Bericht planmäßig am 15. Oktober. Die Verschiebung betrifft damit nicht nur den Kalender: Das Projekt reagiert auf Befunde, die im laufenden Release-Zyklus noch bewertet und gegebenenfalls behoben werden müssen.

Peter Eisentraut, PostgreSQL-Core-Committer und Vizepräsident bei EDB, beschreibt dabei zwei Arten von Problemen. Einige zurückgezogene Funktionen hätten grundlegende Architektur- oder Designmängel, die sich nicht ohne Weiteres innerhalb einer kurzen Beta-Phase ausräumen ließen. Daneben seien zahlreiche Randfälle sichtbar geworden, die jeweils klein wirken, in ihrer Summe aber erhebliche Prüf- und Behebungsarbeit verursachen. Dem Bericht zufolge wurden – je nach Zählweise – etwa acht bis zehn wichtige Funktionen aus PostgreSQL 19 herausgenommen.

KI findet mehr – die Bewertung bleibt menschliche Arbeit

Die neuen Prüfwerkzeuge haben nach Eisentrauts Darstellung nicht einfach von KI erzeugten, mangelhaften Code aufgespürt. Viele der betroffenen Funktionen waren bereits entwickelt, bevor LLM-basierte Programmierung und Prüfung diese Reife erreicht hatten. KI-Werkzeuge untersuchten vielmehr vorhandenen, traditionell geschriebenen Code erneut und machten Schwachstellen sichtbar, die früher möglicherweise erst nach der Veröffentlichung und im praktischen Betrieb aufgefallen wären.

Einzelne seltene Fehler hätten sich sonst womöglich über Jahre verteilt gezeigt. Nun können automatisierte Prüfungen solche Randprobleme in kurzer Zeit bündeln. Das beschleunigt die Entdeckung, nicht automatisch die Lösung: Auch wenn eine Korrektur am Ende nur wenige Codezeilen umfasst, müssen Entwickler den Bericht nachvollziehen, seine Auswirkungen prüfen, eine passende Änderung entwickeln und Regressionen ausschließen. Bei Dutzenden von Befunden wird die verfügbare Zeit der Maintainer schnell zum Engpass.

Hinzu kommt, dass KI-Berichte nicht automatisch echte Fehler darstellen. Der InfoQ-Bericht zitiert Entwickler, die von einem erheblichen Anteil unzutreffender oder kontextloser Meldungen berichten. Ein internes Prüfsystem habe beispielsweise nur etwa ein Achtel seiner Hinweise als gültig bestätigt. Die Zahlen sind Erfahrungsberichte und keine allgemeingültige Messung; sie illustrieren aber, warum eine menschliche Triage unverzichtbar bleibt. Ein vermeintlicher Fehler kann ein akzeptierter Randfall sein – oder tatsächlich auf ein grundlegendes Architekturproblem hinweisen.

Warum Datenbanken besonders komplex zu testen sind

Bei einer Datenbank wie PostgreSQL müssen Funktionen in sehr vielen Kombinationen zusammenspielen. Der Bericht nennt unter anderem Domänen und zusammengesetzte Typen, partitionierte Tabellen, Ansichten, Trigger und Funktionen mit Sicherheitsdefinitionen. Solche Eigenschaften können ineinander verschachtelt auftreten. Eine Änderung, die in einem gewöhnlichen Anwendungsszenario funktioniert, kann in einer seltenen Kombination unerwartete Folgen haben.

Menschen können nicht alle denkbaren Kombinationen im Voraus auflisten und manuell testen. KI-gestütztes Fuzz-Testing kann Testfälle und ungewöhnliche Eingaben generieren, auffällige Ergebnisse erkennen und die Suche entlang eines Fehlerpfads erweitern. Eisentraut hält es deshalb für sinnvoll, solche Verfahren künftig früher in die Entwicklung einzelner Funktionen einzubinden. Werden Probleme erst spät in der Beta-Phase in großer Zahl gefunden, bleibt dem Projekt häufig nur die Wahl zwischen einer riskanten kurzfristigen Reparatur und dem Zurückziehen einer Funktion.

Der Beitrag verweist als Beispiel auf SQL/PGQ, eine Funktion für standardisierte Abfragen von Eigenschaftsgraphen. Sie wurde nach wiederholten Korrekturen und weiteren Prüfungen aus PostgreSQL 19 entfernt. Der Bericht beschreibt außerdem, dass eine KI-gestützte Risikobewertung diese Funktion bereits zuvor als auffällig eingestuft hatte. Das zeigt den möglichen Nutzen solcher Werkzeuge, ersetzt aber nicht die fachliche Prüfung durch die Projektverantwortlichen.