A release that got smaller on purpose

PostgreSQL releases do not usually shrink during beta. A feature or two can be pulled in a normal cycle; core committer Peter Eisentraut puts the usual figure at maybe one. This cycle, by his estimate, about 8 to 10 significant features were reverted from PostgreSQL 19 after the beta period began, some of them quite late. Eisentraut was the developer or committer of several of them, and his October 9 post is the fullest public accounting of what happened. It is also, by his own label, his opinions — firsthand testimony from someone close to the work, not an official root-cause audit.

The first release candidate arrived on October 15. The schedule behind it changed along the way. On September 28, release team member Jonathan Katz scheduled RC 1 for October 15 and general availability for October 29, unless significant issues emerged during the candidate period. On October 10, Katz announced that the release team had moved GA to November 19, one week after the planned scheduled update release: given the volume of fixes added to the back branches, the team wanted those fixes available in a second release candidate, RC 2, scheduled for November 12, before proceeding to GA. The RC 1 announcement on October 15 gives the same reasoning — the November 12 update release will include a large number of fixes, and the team decided to include them in 19 before general availability — with RC 2 scheduled for November 12 and GA planned for November 19.

That official scheduling explanation is separate from Eisentraut's account of the reverts. Neither Katz message, nor the RC 1 announcement, attributes the postponement to LLM review or to the reverts; the official record covers dates and fix volume, and mentions no causes for the reverts at all. The reverted features themselves have not been cancelled, but they are no longer scheduled for 19. Some may be reconsidered for PostgreSQL 20; inclusion is not guaranteed.

Five causes, in one committer's account

The version of this story travelling fastest credits, or blames, AI code review. Eisentraut's post does not. He lists a combination, and warns the mix differs for each reverted feature. Some code, he writes first, may simply not have been good enough. Some features were attempts at problems that turned out too hard, or at least too hard to finish in time. Some had significant architectural defects that would have been hard to fix quickly and during beta.

Then come the two structural causes, both in his analysis rather than in any official finding. He argues that the Vulnpocalypse — a run of security work — absorbed many senior developers between April, when the PostgreSQL 19 feature freeze began, and August, the most recent security release. In his account, the review and testing that normally happens during beta was reduced and picked up again in August, which helps explain why so many issues surfaced late and why the project chose reverts rather than a longer repair effort: he feels that with two more months much of the long tail could have been addressed, but the community preferred to stick to the release schedule, and the security work is ongoing.

LLM-assisted review is the fifth cause, and it is a specific one. Alongside the architectural defects, review surfaced a long tail of relatively harmless edge-case issues. In earlier cycles those would have appeared in production over the following five years and been fixed one by one. Found during beta, they arrive as a single list, in his phrase "like forty defect reports", and each one carries a fixed handling cost however small the fix. Coverage that turns that line into a claim of 40 bugs found by AI is converting an illustration into a statistic. He gave no total, and the official release announcements give no cause at all.

The bar moved after the code was written

The point Eisentraut keeps returning to is timing. Most of the reverted features were written a long time ago, when LLM-assisted code review was not as useful as it is now. In his interpretation, the effective quality bar was raised after the time the features were written and committed — his reading of what changed, not a documented change in the project's acceptance criteria. He is equally direct about the fashionable explanation: this is not a vibe-coding story, because the code was written well before that was a possibility.

His forward look is practical rather than dramatic. Unless LLM review keeps improving at the current rate, he expects the situation to sort itself out, because new features will be written under the review regime that will judge them. His harder example is about the system itself. In PostgreSQL, everything is expected to work with everything else, and the combinations of domains, partitions, views and triggers around a single feature are more than anyone can enumerate by hand. LLM-assisted fuzzing finds those cases quickly, he argues, so it probably has to become part of feature development rather than a beta-period surprise.

What still ships, and what to plan around

The release that remains is not thin. REPACK CONCURRENTLY, which reclaims space without the table lock of VACUUM FULL, ships in 19, along with logical replication of sequences and planner hinting through pg_plan_advice. Eisentraut calls it a great release, and a robust one after the extra scrutiny.

For anyone planning an upgrade, the planning facts are the dates — RC 2 scheduled for November 12, general availability planned for November 19 — and one check: whether a feature your upgrade depends on was among those reverted. SQL/PGQ is the named example, the graph-query syntax standardised in 2023, pulled over unresolved issues after Tom Lane warned that shipping it in 19 would leave post-release bugs unfixable until version 20. If a roadmap depended on SQL/PGQ arriving in 19, that assumption needs revisiting: PostgreSQL 20 is a possible future target for it, not a confirmed delivery date.

Sources

  1. [1] Peter Eisentraut, "The reverts will continue until morale improves" (October 9, 2026; committer's own account, explicitly his opinions: 8–10 reverts against a norm of one, the per-feature mix of causes, the "like forty defect reports" passage, the Vulnpocalypse timeline, the vibe-coding disclaimer, what still ships)Read source
  2. [2] Jonathan S. Katz, "PostgreSQL 19 RC1 and GA release dates" (pgsql-hackers, September 28, 2026; RC 1 scheduled for October 15 and GA scheduled for October 29, 2026)Read source
  3. [3] Jonathan S. Katz, "Updated PostgreSQL RC / GA dates" (pgsql-hackers, October 10, 2026; GA moved to November 19, with an RC 2 on November 12 so the volume of fixes added to the back branches could be included first)Read source
  4. [4] PostgreSQL Global Development Group, "PostgreSQL 19 RC 1 Released!" (October 15, 2026; RC 1 availability, RC 2 on November 12, 2026, general availability planned for November 19, 2026, fixes since Beta 4; no mention of AI or of the reverts' causes)Read source
  5. [5] The Register (October 16, 2026; SQL/PGQ removal and Tom Lane's warning that shipping it in 19 would leave post-release bugs unfixable until v20)Read source
  6. [6] LWN.net, "Eisentraut: The reverts will continue until morale improves" (summary and extended quotation of the Eisentraut post, including the LLM-assisted review passage)Read source