Postgres 19 is late. HN argued about AI; the git log shows a triage problem

Robert Haas, a long-time PostgreSQL developer, wrote last week that Postgres 19 "most likely won't be released until November". The release had shipped between mid-September and mid-October for a decade. His explanation: "LLMs happened". Bugs got "vastly easier to find", and fixing them got easier, "but not to the same degree."

The Hacker News thread argued about whether that is AI's fault. That is the wrong argument. The project's own git history shows a triage problem: more reported bugs, more security fixes, the same reviewers. A project in that position needs a written rule for which bugs block a release, decided before the next release candidate. Arguing each bug on its merits during beta is how three features got pulled in three weeks.

What the git log says

Haas compared 8 April to 25 September in 2025 and 2026. We cloned the GitHub mirror and recounted, through the end of 25 September. Our totals land within 3% of his. Then we read the commit trailers he did not count.

Two rows matter most. Commits crediting a reporter roughly doubled, and the number of people credited rose by 70%: this is not one prolific bot. And the prior release took 38 distinct CVE fixes in the window, against 4 a year earlier. Haas says that security work pulled reviewers away from deciding what to revert.

The AI credit is visible in the trailers. One August fix to PL/Perl says "Claude Code found the instance in hstore_plperl, and I found the others by code auditing" (commit c0641ae). Eleven master commits name a tool or lab directly in Reported-by:, from "Claude Code (via Noah Misch)" to "OpenAI Codex Security". That is a floor: most reporters do not say how they found a bug.

What HN argued

We read all 77 comments from 62 authors and sorted each into one camp. 29 were off-topic: Postgres alternatives, pgrust, and general arguments about AI.

The largest camp is about capacity. One commenter who receives reports wrote "About half of AI bug reports I get are invalid" (0c3ca83). Another commenter put it more bluntly: "They found a more efficient way to play Whac-A-Mole with bugs, they didn't find a way to reduce bugs" (noosphr).

The reporter side has the same problem. tibbar, who hunted Postgres bugs with AI help this summer, had more than they could report and "settled for a dozen or two out of hundreds of candidates" (tibbar). Triage happened twice: once by the reporter, once by the committers.

The best exchange was about whether finding bugs is really the easy half. hopa argued search tasks are easy to verify. Simon Willison disagreed: "The most common error for a search task is omission, and that's really hard to spot" (simonw). Both are right: a reported bug is easy to confirm, and a clean scan proves almost nothing.

The "doubt the framing" camp was answered from the data side. StilesCrisis pointed out that the reports come "from all corners of the codebase, not just things changed in the last 1-2 years" (StilesCrisis). The trailers agree: the fixes land on old branches.

The takeaway: write the blocking rule down

Postgres already has the mechanism. Its versioning policy promises bug and security fixes in a minor release "at least once every three months". A bug that does not block a major release still gets fixed in the next minor release. The question this year was which bugs were allowed to hold up a major release, and that was answered feature by feature, late.

Two comments sketch the rule. On a late segfault: "If you are at the RC stage and still uncovering segfaults, "rip the feature out" is probably the only choice" (StilesCrisis). On old behaviour: "Old bugs are sometimes undesirable to fix because other systems/users have come to rely on their behavior" (tibbar).

Put together, that is a severity bar any project can write before beta:

• Blocks the release: wrong query results, data loss, crashes and security bugs in code new to this release. The fix is to revert the feature, not to hold the date.
• Ships in a minor release: the same classes of bug in old code, already in users' hands.
• Waits: cosmetic issues, and old behaviour that others may rely on.
• Goes to the back of the queue: any report without a reproducing case, whoever or whatever found it.

Bug finders will keep getting faster; reviewer hours will not. A written rule is what lets a release ship while the bug count still rises.