For a decade PostgreSQL shipped on a clock you could set: major releases arrived “no earlier than the middle of September, and no later than the middle of October.” PostgreSQL 19 most likely won’t be out until November, and might slip further. When Robert Haas, a PostgreSQL committer, explained the delay, the cause was not a feature that failed or a toolchain that broke. Strangers on the internet had gotten very good at finding real bugs in a codebase with forty years of them, faster than the humans who fix them could absorb.

The damage shows in the release itself. Three major features — UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries, ALTER TABLE MERGE/SPLIT PARTITION — were pulled between August 27 and September 15, late enough in the beta period that one revert would be unusual, let alone three. Haas went looking for where the committers’ time went, and counted commits. Between feature freeze on April 8 and September 25, the branch carrying the upcoming release took 724 back-patched commits in 2025 and 1,169 this year; one stable branch older, 248 and 433. His one-sentence cause: “a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs, and the PostgreSQL committers have been very, very busy fixing them.”

I recounted both windows from the public git history before writing this — commit dates on the GitHub mirror, April 8 through September 25 inclusive — and no figure diverges from his by more than about two percent: 733 and 1,178 on the release branch, 248 and 436 one branch older, jumps of roughly 61 and 76 percent. One sentence of his prose only parses once you stop reading it as arithmetic: master-only work, he writes, “declined slightly,” while the raw master totals rose about 40 percent, so he must mean commits that touched master alone, not the ones back-patched from it.

His two factors are worth separating. 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.” The second factor is quieter: hours that would have gone into reviewing what shipped in v19 went instead into fixing the back-branches, and that is why it took so long to see which of the new features had to come out. His verdict on the delay is that it is not particularly concerning — the project’s quality bar, charging interest.

What makes this different from the summer’s report floods is the part the summer’s advice doesn’t cover. When PHP shipped 15 CVEs alongside “more than 100 reports that turned out to be invalid, duplicates, or not reproducible,” and when curl’s maintainer measured “over 90% of all submissions” as below HIGH, those queues were full of things that weren’t true, and the remedy was sorting: policy at intake, evidence-gated triage. Haas’s queue is not full of things that aren’t true. His read is that committers were “about as conservative in 2026 as they were in preceding years” and simply got caught more often. A queue where every item is real work cannot be triaged away. The bottleneck moved one stage down the pipeline, from report review to fix review, and fix review is people.

A few hours after this went up, the other disposition arrived from a maintainer sitting in the same flood. Simon Willison calls llm his project most affected by AI-assisted PRs, and he is “not finding it to be a problem”: Opus 5.5 or GPT-6 Astra “help me with triage to spot the most useful fixes,” and the 0.37 release includes fixes from 12 authors, “almost all AI-assisted.” The move is smaller than it sounds, and it is not a model doing the review. An AI-assisted PR stops being a candidate merge and becomes what he calls “bug reports with attached examples”: “sometimes I land them, sometimes I implement my own fix.” A model answers whether a submission deserves his attention; whether a patch is correct reaches him only for the ones he chooses to consider, and sometimes never, because he writes his own fix instead. Haas’s queue does not fold that way. A PostgreSQL committer is the correctness question, twelve authors is not eleven hundred back-patches against forty years of behavior, and the cost of a wrong merge is not a filed issue but somebody’s data. What Willison’s post measures is the price of the same flood when the correctness decision can be deferred: twelve authors’ worth of attention, and no slipped calendar.

Days after Haas’s post, Trail of Bits published the other answer. Backporting security fixes at scale with Codex starts from the job Haas’s numbers imply: carrying fixes to the old branches nobody upgrades off of — about 95% of Ubuntu installations are LTS, and on Debian’s popularity contest about 96% of installed kernels are older stable series. Artem Dinaburg’s yardstick for how much of that runs known bugs that already have fixes elsewhere: 2,006 CVEs unfixed in the 5.10.y kernel branch alone, 213 of them high or critical; in Debian 13, 4,562 unique CVEs across 1,128 source packages. He calls it a measuring stick that both over- and under-counts, not a census. I did not recount it, and I have not run their Codex workflow; the half-hour figure below is their measurement of their own pipeline.

The pipeline is the part worth stealing. Agents identify missing fixes, adapt patches to the old trees, assemble validation evidence, run tests, and prepare submission packets; engineers review and submit. A straightforward backport now costs about thirty minutes of human attention, an involved one around three hours — down, by their own subtitle, “from days to hours per fix” — and the estimate covers preparation and review only; regression testing and maintainer acceptance are excluded, and they say so in the same breath. By October 29 the project had delivered 149 CVE fixes into stable kernel trees, having started with what Dinaburg calls money on the sidewalk: patches that applied cleanly to the stable trees and had simply never been pulled in. The maintainers, he notes, applied them graciously.

The catch-up math is what ties the two posts together. Two thousand fixes at the straightforward-case half hour is a thousand hours of one human reviewer — half a working year — and that is one branch of one project, before the involved cases and the testing the estimate excludes. That is the shape of the question Haas ends his post on: “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?” Postgres answered one way this quarter: ration the review, slip the calendar, keep the bar. Trail of Bits answered the other way, where an answer can work at all. A backport’s correct behavior already exists upstream, which is exactly what makes its review mechanizable. The review Haas says cannot be delegated — choosing among fixes when each one costs somebody a compatibility break or a new failure mode — has no upstream answer to check against, and it is the half that moved the calendar.

If you run old software, both posts point at you. The yardstick reads as exposure from your side: CVE-2026-98432, a critical remotely exploitable flaw in the Linux TCP stack, was patched upstream and still missing from distribution kernels weeks later. It is high-profile enough to land everywhere soon; the obscure ones are what the yardstick is measuring. The finding side is cheap for attackers too — Dinaburg’s warning is that “a swarm of cyber-capable AI agents can cut through a network of stable, known-vulnerable software like a hot knife through butter” — and his firm’s Patch the Planet is taking applications from projects that want the help.

The instrument worth copying is also the cheapest one in either post. Haas counted commits by branch and let the histogram carry the argument; Dinaburg published a yardstick and disclaimed its precision in the same breath. The diversion of a release’s review capacity into its back-branches was sitting in the branch histogram, reproducible from public history, before it showed up as a November. The counting is the part anyone can repeat this afternoon.