> ## Content Index > Fetch the complete content index at: https://www.dailyferment.com/llms.txt > Use this file to discover other available public pages before exploring further. # AI review found more Postgres bugs than there was time to fix - URL: https://www.dailyferment.com/ai-code-review-postgres-19-what-not-to-fix/ - Published: 2026-10-17T19:13:49.000Z - Updated: 2026-10-17T19:13:49.000Z - Description: Postgres 19 lost about eight to ten features in beta, partly because LLM review found more small defects than the window could hold. Radiology already has a rule for that. - Author: Rana Bilal Zafar - Tags: Engineering, AI, #reframe A PostgreSQL release usually loses maybe one feature during beta. Postgres 19 lost about eight to ten. Peter Eisentraut, one of the project's committers, gave those numbers on 9 October, and on 16 October The Register reported that the release has slipped to around 19 November. The project's open items page now lists 19 November as the planned date. Part of his explanation is the part I keep coming back to. With LLM-assisted code review, he wrote, problems "can get found much faster", and then you are looking at "a list of like forty defect reports". Each one might be a "three-line fix on average", but there is a "fixed overhead to dealing with each of these", and "then you run out of time." So here is what I'm trying to work out. When a machine can find defects faster than people can close them, what decides which ones are allowed to block a release? ## What actually happened to Postgres 19? Feature freeze was 8 April. Beta 1 came on 4 June, Beta 4 on 24 September, and the first release candidate on 15 October. Along the way, MERGE and SPLIT PARTITION was reverted on 27 August with a commit message citing "multiple design issues which are too late to address in this release cycle". SQL/PGQ property graphs went on 7 September, taking 47 commits with them. Tom Lane had said he would "bet dinner" that shipping graph queries in 19 would mean bugs that could not be fixed until 20. Eisentraut is clear that this is not about AI-written code. The features "were written a long time ago when LLM-assisted code review was not as useful", and he says the situation is not due to "vibe coding". What changed is the review. In his words, "the effective quality bar has been raised after the time the feature was written and committed." ![Two flows side by side: LLM-assisted review leads to a list of about forty defect reports and 8 to 10 reverted Postgres 19 features; sharper CT scanners find small lung nodules, and a rule written in advance says no routine follow-up under 6 mm for low-risk patients](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/10/df53-triage.png) Same pressure, two answers: Postgres reverted features; radiology wrote the triage rule first. Sources: Eisentraut, The Register, Fleischner 2017. ## My first reaction, and why it's only half right My first reaction was that this is a code quality story. The tools found real bugs, the features were not ready, and a project that pulls unready features is doing its job. Eisentraut allows for that too: "maybe the code was just not good enough." Reading it again, I think two different problems are ending in the same revert. One is design defects, the kind no amount of triage saves, and the MERGE and SPLIT message reads like that. The other is the forty-defects passage: a long tail of small issues, each cheap, that together don't fit in the time left. I'd call that a capacity problem. The two look identical from outside because both end with a feature moved to the next version. The second one is new. Review used to be the slow part. Now finding is cheap, and fixing, testing and agreeing are as slow as they always were. ## Where has detection outrun capacity before? Radiology. As CT got sharper, scans ordered for one reason started showing small things in the lungs that nobody was looking for. One estimate cited around the American College of Radiology's guidance is more than 1.5 million pulmonary nodules found on chest CT each year. The coverage of the ACR's own white paper on incidental lung findings says low follow-up rates and disagreement over what to do "plague the field". The field's answer was not "follow up everything". The Fleischner Society's 2017 guidelines, as summarised in the University of Washington's radiology reference, say a single solid nodule under 6 mm in a low-risk patient needs "No routine f/u". In a high-risk patient the answer changes to an optional CT at 12 months. The ACR white paper sets out to define what counts as an incidental finding, to weigh risks and benefits for the patient, and to standardise the words radiologists use to say how confident they are. The 6 mm figure matters less to me than when the rule was written: in advance, by people not looking at a particular patient, so the person reading a scan is not deciding alone, under time pressure, what a small finding is worth. A small nodule isn't declared harmless. It's declared not worth chasing now, with a named condition that changes the answer. ## What would the software version look like? Postgres has some of the pieces. There is the open items list, a culture that accepts reverts, and, Eisentraut says, talk of an "experimental" status for features that nobody has worked out yet. Snowflake's engineering blog noted in September that the project has no official AI contribution policy yet. What I didn't find in anything I read is a written threshold: which classes of machine-found defect block a beta, which go on a known issues list with the release, and which wait for the next version. I read the blog posts, the wiki and the news coverage, not the full pgsql-hackers archive, so someone may well have proposed one there. Eisentraut expects this to sort itself out "unless the capabilities of LLM-assisted code review keep improving at the current rate". That condition is the important part. If the tools keep improving, the bar moves after the code is written in every cycle, not just this one. A threshold written once would need a date on which it gets looked at again. I wrote about Epic banning [hand-written code](https://www.dailyferment.com/epic-no-hand-written-code-ada-mandate/) on 14 October. That was the writing end of the pipe. This is the review end, and it seems to have the harder problem. ## How sure am I? Established: the number of reverts, the dates, and Eisentraut's explanation in his own words. Inferred: that a real share of the slip is triage capacity rather than code that was simply bad; he names both causes and doesn't split them. A guess: that a threshold written before beta would have kept any particular feature in 19\. The design-defect reverts would probably have gone anyway. The claim, in one sentence: when finding defects gets cheaper faster than fixing them, a project needs a rule, written before the review starts, for which findings it will not chase this release, and radiology wrote one for small lung nodules long before software review needed it. What I still don't know is whether a rule like that can be written for code at all, where a three-line edge case can turn out to be the one that corrupts data. ## Sources - Peter Eisentraut, [The reverts will continue until morale improves](https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves?ref=dailyferment.com), 9 October 2026. - Lindsay Clark, [Postgres 19 delayed after AI reviewers find more bugs than humans can fix](https://www.theregister.com/databases/2026/10/16/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix/5303471?ref=dailyferment.com), The Register, 16 October 2026. - PostgreSQL wiki, [PostgreSQL 19 Open Items](https://wiki.postgresql.org/wiki/PostgreSQL%5F19%5FOpen%5FItems?ref=dailyferment.com), read 17 October 2026. - Joshua D. Drake, [Two features just left PostgreSQL 19](https://www.commandprompt.com/blog/two-features-just-left-postgresql-19/?ref=dailyferment.com), Command Prompt, 8 September 2026. - Lindsay Clark, [PostgreSQL 19 graph queries fail the would-you-ship-this test](https://www.theregister.com/databases/2026/09/15/postgresql-19-graph-queries-fail-the-would-you-ship-this-test/5296343?ref=dailyferment.com), The Register, 15 September 2026. - Elizabeth Garrett Christensen, [What is happening with PostgreSQL 19?](https://www.snowflake.com/en/blog/engineering/postgresql-19-release-delay-feature-reverts/?ref=dailyferment.com), Snowflake, 16 September 2026. - Health Imaging, [ACR releases new guidance to help radiologists manage incidental lung findings on CT scans](https://healthimaging.com/topics/medical-imaging/computed-tomography-ct/radiology-incidental-lung-findings-ct-acr?ref=dailyferment.com). - University of Washington radiology reference, [Fleischner guidelines for pulmonary nodules 2017](https://sites.uw.edu/eradsite/trauma-radiology-reference-resource/4-chest/fleischner-guidelines-for-pulmonary-nodules-2017?ref=dailyferment.com), summarising MacMahon et al., Radiology, 2017.