Dev News Daily ENDE

PostgreSQL 19 RC 1 ist da, GA am 19. November: Was die späten Rücknahmen bedeuten

Die PostgreSQL Global Development Group hat am 15. Oktober 2026 PostgreSQL 19 RC 1 veröffentlicht. Die Ankündigung nennt den Termin für die allgemeine Verfügbarkeit: 19. November 2026, sofern kein Problem eine weitere Verschiebung oder einen zusätzlichen Release Candidate verlangt. Die Roadmap-Seite des Projekts sah die Veröffentlichung für Oktober vor. Dieser Text ordnet ein, warum sich der Plan verschoben hat und was das für ein geplantes Upgrade heißt.

Warum es einen RC 2 gibt. Die Ankündigung nennt einen konkreten Grund. Das nächste planmäßige Update für die unterstützten Versionen am 12. November wird sehr viele Fehlerbehebungen enthalten, und das Release-Team will diese vor der Freigabe in PostgreSQL 19 übernehmen. Deshalb erscheint RC 2 am 12. November, zeitgleich mit dem Update, und eine Woche später folgt die GA. Für den Umstieg von älteren Versionen bleibt ein Major-Upgrade nötig, etwa mit pg_upgrade oder per Dump und Restore.

Was in Beta 4 behoben wurde. Die Notizen zu RC 1 nennen mehrere Korrekturen an REPACK (CONCURRENTLY), an pg_plan_advice, an neuen Planner-Optimierungen, die davon abhängen, ob ein Ausdruck NULL sein kann, an der automatischen Aktivierung logischer Replikation bei wal_level gleich replica und am parallelen Autovacuum. Der Statistikimport in postgres_fdw läuft jetzt als Eigentümer der Fremdtabelle, und COPY (query) TO ... (FORMAT json) verwendet als JSON-Schlüssel die Spaltennamen der Abfrage samt Aliasen.

PostgreSQL 19 RC 1 ist da, GA am 19. November: Was die späten Rücknahmen bedeuten
PostgreSQL 19 RC 1 ist da, GA am 19. November: Was die späten Rücknahmen bedeuten — Dev News Daily

Die Rücknahmen. Die eigentliche Geschichte dieses Zyklus kam eine Woche früher. Am 9. Oktober schrieb Peter Eisentraut, langjähriger Committer, dass nach Beginn der Beta „etwa 8 bis 10 bedeutende Features“ aus dem Zweig 19 zurückgenommen wurden, manche davon spät – üblich sei vielleicht eines pro Zyklus. Er nennt mehrere Gründe, die je nach Feature unterschiedlich zusammenwirken:

  • manche Features hatten gravierende Architekturfehler, die sich in der Beta nicht schnell beheben ließen;
  • daneben kam ein langer Schwanz eher harmloser Randfall-Fehler, die früher nach seinen Worten über fünf Jahre ans Licht gekommen wären; LLM-gestützte Code-Reviews finden sie nun schnell, „und dann starrt man auf eine Liste von etwa vierzig Fehlerberichten“;
  • viele erfahrene Entwickler waren von April bis August mit Sicherheitskorrekturen beschäftigt, Review und Tests der Beta zogen daher spät an;
  • PostgreSQLs Prinzip „alles funktioniert mit allem“ macht manche Features kaum von Hand testbar; er schlägt vor, LLM-gestütztes Fuzzing in die Feature-Entwicklung aufzunehmen.

Er betont, dass der zurückgenommene Code lange vor „Vibe Coding“ entstanden ist. Das Projekt hielt am Zeitplan fest, statt für weitere Korrekturen zu verschieben, und diskutiert weiter, wie sich Features mit einem Status „experimentell“ einchecken ließen.

Was trotzdem kommt. Eisentraut nennt REPACK CONCURRENTLY, logische Replikation von Sequenzen und Planner-Hinweise mit pg_plan_advice als Höhepunkte und erwartet, dass die zurückgenommenen Features wiederkommen, mehrere davon in PostgreSQL 20. Für den Betrieb heißt das praktisch: jetzt gegen RC 1 testen und RC 2 vom 12. November als den Build betrachten, der vor einem GA-Upgrade zu prüfen ist.

Quellen: PostgreSQL Global Development Group, „PostgreSQL 19 RC 1 Released!“ — https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/ ; Peter Eisentraut, „The reverts will continue until morale improves“ — https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves

Primärquelle
PostgreSQL Global Development Group
https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/
Geschrieben von Victoria Shinder.