LLMs Found So Many Postgres Bugs That Version 19 Slipped to November
Postgres 19 is late, and it's AI's fault
PostgreSQL 19 will miss its usual mid-September to mid-October window, likely landing in November, after three major features were reverted between late August and mid-September. The cause: LLMs are surfacing decades-old bugs far faster than humans can fix them. Back-patched commits jumped over 60% year over year, and patches to prior releases rose 74%, diverting committer time away from release review.
It is not a long delay in the grand scheme of things, and it emerges directly from the project's concern for quality.
- CharlesW
> This year is going to be different. PostgreSQL 19 most likely won’t be released until November… […] So, what happened? The short answer is that LLMs happened. […] There’s a huge amount of code, and that code contains a huge number of bugs. […] What’s different now is that it’s become vastly easier to find those bugs.
This seems…good?
That it might disrupt the project's "traditional" release cadence a bit doesn't seem terribly bad in light of the alternative, which is shipping another major update with bugs which have apparently haunted the codebase for some time.
- tibbar
I did a little AI-assisted bug-hunting in Postgres this summer in between jobs, and the haul was staggering. Multiple serialization anomalies (eg [0] [1] [2]), foreign key integrity issues ([3] [4]), planner correctness bugs such as [5]. Various CVE-worthy vulnerabilities. An unfixable timezone bug [6]. The list got so long that I had to triage what I even had time to report, and settled for a dozen or two out of hundreds of candidates. Now imagine the entire world doing this.
[0] Write skew observed under serializable isolation:
https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...
[1] Serializable anomaly: duplicate primary keys:
https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...
[2] SERIALIZABLE can commit write skew after SSI summarization:
https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...
[3] Fix temporal foreign key validation of pre-existing rows
https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...
[4] Lost lock during toasting allows FK violation
https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...
[5] Partition pruning can incorrectly exclude a RANGE default partition
https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...
[6] timestamp vs. timestamptz comparisons inconsistently ordered under DST : https://www.postgresql.org/message-id/flat/c22286ad6268347c6...
- droppedasbaby
I guess the real challenge is figuring out how to scale verification, cause discovery isn't the bottleneck anymore. Generating more bug reports doesn't necessarily translate into faster fixes if the same small group of maintainers still have to validate the reports, review fixes, etc.
- hopa
I feel like AI is amazing for read only “search” tasks (query this, look for bugs, find vulnerabilities) but it’s not quite as good for “write” tasks like “add this feature”. Search tasks are easily verified, code changes are much harder to verify
- flossly
“A wizard is never late, nor is he early; he arrives precisely when he means to” -- Gandalf