PostgreSQL 19 Slips to November 19 as LLM-Found Bugs Push Stable-Branch Commits Up 61%

TL;DR

Robert Haas, a PostgreSQL committer at Databricks, says PostgreSQL 19 will miss the mid-September to mid-October window every major release has hit for a decade, and his explanation is two words long: "LLMs happened." Between feature freeze on April 8 and September 25, commits to the release's stable branch rose from 724 in 2025 to 1,169 in 2026, and fixes back-patched to the previous release rose from 248 to 433. Four headline features were pulled in a three-week span. RC 1 shipped October 15, RC 2 is planned for November 12 and general availability for November 19. We recounted the numbers from the git mirror and grepped the commit messages: 17 fixes on the 19 branch in that window credit Claude or OpenAI Codex by name. A year earlier the count was zero.

What slipped

Haas's post first ran on the Neon blog on October 21 and he reposted it on his own blog on October 30, which is when Hacker News picked it up. The schedule it describes is now official. The RC 1 announcement says the November 12 update release for the older branches will carry "a large number of fixes," so the release team decided to fold them into 19 first, hence a second release candidate that day and GA a week later, "unless an issue is discovered that requires a delay."

The reverts are the louder part. Reverting a patch shortly after freeze is routine; reverting several large ones in the last weeks of beta is not, and that is what happened on the 19 branch:

• August 27: ALTER TABLE ... MERGE/SPLIT PARTITION, 14 commits removed.
• September 7: SQL Property Graph Queries (SQL/PGQ), 47 commits removed, by its own author Peter Eisentraut.
• September 15: UPDATE/DELETE FOR PORTION OF, 23 commits removed.
• September 16: online data checksum transitions, 30 commits removed, the message citing fixes during beta that raised "concerns about further issues after GA."

Smaller reverts landed the same fortnight: the new pg_get_*_ddl() functions, two CREATE SCHEMA changes and a casefolding change, per Command Prompt's weekly log. Snowflake's Elizabeth Garrett Christensen counted 53 reverts on the branch since beta began. We confirmed the four big ones and their dates in the repo.

The commit math

Haas's argument rests on one comparison. Take the window from feature freeze to September 25 in each of the last two years and count commits. On master, 1,037 became 1,443. On the stable branch for the release in progress, 724 became 1,169. On the branch for the previous release, meaning fixes judged serious enough to back-patch, 248 became 433. Subtract the stable branch from master and the commits that only touched master, the new-feature work, fell slightly, from 313 to 274. All of the growth was bug fixing.

We ran the same counts against the GitHub mirror on November 2 and got 1,056 and 1,477 on master, 738 and 1,182 on the stable branches, and 250 and 437 on the back-patch branches. Our totals run 1 to 3 percent above his, which is what you expect from a later clone and a different timezone cutoff, and the ratios are the same: stable-branch commits up 61 percent, back-patched fixes up 75 percent.

Haas rules out the obvious alternative, that committers simply got sloppier: "it seems likely that PostgreSQL committers were about as conservative in 2026 as they were in preceding years, but a lot more of the mistakes they made were quickly found by LLMs." The back-patch number is the tell. A sudden rise in fixes to a release that shipped a year ago cannot be explained by this year's feature work; those bugs were already there.

Who found the bugs

The commit log says so in its own words. We grepped every commit on the 19 branch in Haas's window for Claude, Codex, Gemini, Copilot, ChatGPT or "LLM" and got 17 genuine hits: 14 credit Claude and three credit "Amy Burnett (OpenAI Codex Security)" as reporter. The same grep over the equivalent 2025 window on the 17 branch returns nothing. Four of the Claude commits carry the trailer Reported-by: Claude Code (via Noah Misch), three say "Ben Morris in collaboration with Claude and Anthropic Research," two of Peter Geoghegan's say "Claude Code found this problem" or "diagnosed this problem" and note the committed test is a trimmed version of the one the model wrote, and two of Tom Lane's patches open with a disclosure that early drafts "were made with Claude Opus 4.8."

The first commit in PostgreSQL's history to credit Claude Code or Claude landed on May 11, 2026, a fix for unbounded recursion in startup-packet handling. August alone has ten.

Treat 17 as a floor. PostgreSQL has no convention for crediting tools, so most LLM-found bugs arrive as ordinary mailing-list reports with a human name on them. One HN commenter, tibbar, described spending the summer between jobs doing AI-assisted bug hunting on Postgres and finding serialization anomalies, foreign-key integrity failures and planner correctness bugs, then "settled for a dozen or two out of hundreds of candidates" because triage took longer than discovery. "Now imagine the entire world doing this."

The scary patch contest

The project saw it coming in August. On August 25 Haas mailed pgsql-hackers under the subject "scary patch contest," reviving an old community tradition with a new judge: he had asked Claude to rank the v19 patches by the number and kind of fixes they needed after freeze, per LWN's write-up. REPACK and REPACK CONCURRENTLY topped the list at 28 fixes between them, including a data-loss fix. Online checksums had about 25. FOR PORTION OF had 17, three of them security fixes, and later reports pushed that past 30. SQL/PGQ had 17 that Haas rated low severity, which did not stop Tom Lane from saying he was "quite afraid" of it and betting a dinner on post-release bugs that could only be fixed in v20.

Three of the five patches on that list were reverted within a month. Melanie Plageman of the release management team asked the question the whole thread circles: are LLMs finding bugs that would have surfaced anyway, just sooner? Bruce Momjian called the situation "unprecedented" and backed an extra beta, which became beta 4 on September 24.

Why finding got faster than fixing

Haas names two mechanisms. First, volume: "LLMs can draft fixes, but those fixes aren't always correct or compliant with PostgreSQL standards. So, they still need to be reviewed and committed by humans, and those humans have not gotten any smarter between 2025 and 2026." Second, attention: committer time that would have gone into deciding what to revert before 19 shipped went into security issues and back-branch bugs instead, so the revert decisions came late.

Picture a beach where people have been dropping coins for thirty years, and this summer every tourist got a metal detector. The beeping is constant and almost all of it is real. The digging crew is the same few dozen committers it was last year, and every coin has to be dug up by hand to standards, then reburied correctly in up to five supported branches. In PostgreSQL's case the crew also has to decide which of this year's new sandcastles to knock down before the tide of GA.

Haas is calm about the short term: "It is not a long delay in the grand scheme of things, and it emerges directly from the project's concern for quality." The next paragraph is less calm. "Given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate? Right now, I'm not sure." He ends with a warning aimed wider than Postgres: "Every feature that we write from now until the end of our careers will be scrutinized by AI, and things that would have escaped forever unnoticed in an earlier era will now be found, perhaps in a matter of hours."

What this means if you maintain anything old

This is the opposite problem from the one the Linux Foundation's survey described two weeks ago, where maintainers estimated a quarter of incoming pull requests are AI slop. Postgres is not drowning in bad patches; as one HN commenter pointed out, the reverted features were written by humans. It is drowning in good bug reports, which is harder, because you cannot close a valid bug with a template.

Three things follow for anyone running a project with a long history. Your bug backlog is about to be discovered for you, so decide now whether you want to be the one holding the detector. Review capacity, not authoring capacity, is the constraint, so the useful AI investment is tooling that turns a report into a reviewed, tested, back-patch-ready fix rather than tooling that writes more features. And if your release process assumes a fixed number of post-freeze bugs, it is now wrong, and an extra beta is cheaper than a revert at RC.

Caveats

• The headline counts are Haas's. Our recount on November 2 runs 1 to 3 percent higher on every figure, which is consistent with commits whose author dates fell inside the window landing after his cutoff. The ratios do not move.
• Our 17-commit grep catches only messages that name a tool. It undercounts LLM-found bugs by an unknown multiple and says nothing about reports humans verified before filing.
• Snowflake's 53 counts individual revert commits, not distinct features.
• November 19 is a plan, not a promise. The RC 1 announcement conditions it on nothing new turning up, and Haas wrote that further postponement "is not impossible."
• Haas's is one committer's reading of the cause, though nobody on the hackers list or the HN thread offered a competing one.

Key Takeaways

• PostgreSQL 19 missed its decade-long September-to-October window; RC 2 is planned for November 12 and GA for November 19.
• Post-freeze commits to the release branch rose 61 percent year over year and back-patched fixes rose 74 percent, while new-feature commits on master fell.
• Four large features were reverted between August 27 and September 16, three of them after Haas had Claude rank patches by post-freeze fix count.
• 17 fixes on the 19 branch in the window credit Claude or Codex in the commit message, against zero in 2025; the first Claude-credited Postgres commit is from May 11, 2026.
• The bottleneck is human review of valid reports, not slop: LLMs draft fixes, but committers still have to verify them to project standards across supported branches.
• Any project with decades of history should expect the same wave and budget review capacity accordingly.

Sources: Robert Haas, "Postgres 19 is late, and it's AI's fault" (Neon), the same post on rhaas.blogspot.com, PostgreSQL 19 RC 1 announcement, postgres/postgres git mirror, LWN, PostgreSQL 19's "scary patch contest", Snowflake, What Is Happening with PostgreSQL 19?, Command Prompt, 6 Reverts for PostgreSQL 19, Hacker News discussion, LF Research survey press release