PostgreSQL 19 will ship on November 19 instead of early October, and one of the reasons the project gives is that LLM code review found bugs faster than the committers could fix them. Release candidate 1 came out on October 15. A second release candidate lands on November 12. Somewhere between eight and ten features that were committed before the April 8 feature freeze have been pulled from the branch and pushed to version 20.
That is the short version. The long version is a mailing list thread, a blog post from a core committer, and a wiki page full of reverts, and it reads like a preview of what every large codebase is about to go through.
What got cut and when
Jonathan Katz posted the schedule change to pgsql-hackers on October 10. RC1 stayed on October 15. GA moved to November 19, one week after the regular quarterly update release on November 12. The reason he gave: so many fixes have gone into the back branches that the release team wanted them in an RC2 before calling 19 done. He called it "an atypical major release cycle." The roadmap had GA penciled in for October, and most years the release lands in September or early October.
The open items wiki lists what came out. SQL/PGQ property graph queries. UPDATE and DELETE FOR PORTION OF. ALTER TABLE MERGE and SPLIT PARTITION. Online data checksums. The new output formats for pg_dumpall. The new pg_get_*_ddl() functions. GROUP BY ALL. The switch to lz4 as the default TOAST compression. Elizabeth Garrett Christensen, writing on the Snowflake engineering blog on September 16, counted 53 reverts since beta 1 in June, against about 44 for the entire PostgreSQL 18 cycle. Several more came after she wrote that.
What stayed in: REPACK and REPACK CONCURRENTLY, which replaces VACUUM FULL and its table lock. Parallel autovacuum. Logical replication of sequences. The pg_plan_advice extension. Those are the features that justify the upgrade, and three of the four show up in the RC1 fix list with the words "several fixes" next to them.
The contest that started it
On August 25, Robert Haas opened a thread on pgsql-hackers he called the scary patch contest. He had asked Claude to rank the version 19 features by how many bug fixes each had needed since feature freeze. The list:
- REPACK and REPACK CONCURRENTLY: 28 fixes
- Online data checksums: about 25
- FOR PORTION OF: 17, three of them security issues
- SQL/PGQ: 17
- Referential integrity fast path: about 16
- postgres_fdw statistics import: 7
Around 110 fixes since the freeze, across six features. Haas said he was "pretty scared" about the first three and asked whether any should be reverted. Tom Lane answered later that day about SQL/PGQ: he would "bet dinner" that shipping it would mean bugs found after release that cannot be fixed until version 20, because the open issues needed catalog changes. It was reverted. Andres Freund drew a different line. Online checksums were lower risk because only a superuser can reach them. FOR PORTION OF and PGQ were higher risk because any user without elevated privileges could. Both of those are gone from 19 too.
Four comments in that thread explain the rest. Melanie Plageman suggested the LLMs were surfacing bugs sooner rather than creating new ones. Nathan Bossart confirmed the release management team was using them to find missing open items. Daniel Gustafsson pointed out that most of the version 19 features were written and reviewed before the current tools existed. David Rowley said free review cycles were scarce enough this year that lowering the bar for a revert was reasonable.
Eisentraut's explanation
Peter Eisentraut committed or authored two of the reverted features. On October 9 he published a post titled The reverts will continue until morale improves, and it is the most honest piece of release engineering writing I've read this year.
He lists several causes and refuses to pick one. The code may not have been good enough. The project may have taken on too much. Some features had design flaws that could not be fixed during beta. Senior developers spent April through August on security work (the August update release for PostgreSQL 18 fixed 28 CVEs, where a normal one fixes two or three), which ate the review time that beta usually gets.
And then the part The Register's Lindsay Clark put in her headline. LLM code review turned up a long tail of edge case bugs that in any earlier year would have been found by users after release, one at a time, over two or three point releases. Now they arrive as a list of around 40 defect reports in one go. Each needs a fix, a review, and a commit. The people who can do that work are the same handful of committers, and there are no more of them than there were last year.
His phrasing: "The effective quality bar has been raised after the time the feature was written and committed." He is clear that none of this was vibe coding. The code predates the tools that found the problems with it.
The bottleneck moved
I've spent a long time on the receiving end of database point releases, and the pattern Eisentraut describes matches what I'd expect from any mature project that turns a good reviewer loose on old code. Finding bugs used to be the expensive step. Fixing them was the cheap one, because you found them slowly enough that the fix queue never backed up. PostgreSQL just discovered what happens when finding becomes close to free. The queue backs up in weeks, and the only lever left is scope.
The project pulled that lever, which is the correct call. A feature that ships with a known catalog defect gets frozen for a year, because PostgreSQL cannot change the catalog in a minor release. A feature that gets pulled comes back in twelve months with its bugs fixed. If you run Postgres, you want the second thing every time, even though it means the version you upgrade to in December has less in it than the beta you tested in July.
The schedule tells you something else. The November 12 update release carries enough fixes to the back branches that the release team didn't want to ship 19 without them. The same review that gutted 19 is finding bugs in 18, 17, and 16. Expect that update to be larger than usual, and read the notes before you apply it.
For anyone maintaining their own software, the lesson is about capacity. Pointing a model at your codebase will give you a defect list longer than your team can clear this quarter. That is the new normal, and the fix is a triage process you decide on before the list arrives, with a revert bar you're willing to enforce. PostgreSQL has about 30 committers and a review culture that goes back three decades, and it still took them from June to October to work through it. Your project will not do better by accident.
Eisentraut thinks this sorts itself out in future cycles, since next year's features will be written and reviewed with the same tools that are now tearing apart this year's. He adds one condition: unless review capability keeps improving at its current rate. I'd take the other side of that. The tools will keep getting better, the commit rate will not keep pace, and PostgreSQL 20 will have its own revert list by next August.
