InfoQ 中文 · 10/23/2026, 17:58:35
PostgreSQL 19 Delayed as AI Review Exposes Legacy Defects
PostgreSQL 19 has been delayed to November due to insufficiently verified fixes and the withdrawal of nearly 10 features. Core committers clarified that the delay was not caused by AI-generated poor code, but rather by LLM-assisted reviews and fuzzing exposing deep-seated architectural and edge-case defects that had long remained undetected. This event signals a paradigm shift in open-source quality validation driven by AI.
SOURCE COVERAGEFull Original Report
Contents4 sections
PostgreSQL 19 has been delayed due to a large number of insufficiently verified fixes and the withdrawal of nearly 10 features, with an additional RC2 release added to strengthen community testing. The root cause is not low-quality AI-generated code, but rather that LLM-driven automated reviews and fuzzing have exposed deep-seated defects in legacy code that had long gone undetected.
AI-assisted reviews caused five years' worth of historical defects to surface en masse during the Beta phase; feature withdrawals were primarily driven by edge cases and concurrency logic flaws revealed by new tools; PostgreSQL's release process is passively adapting to the paradigm shift in quality verification brought about by AI.
This article is suitable for database kernel developers, open-source project maintainers, and AI for Systems engineers.
Recently, the release of PostgreSQL 19 encountered rare turbulence. The PostgreSQL team announced that PostgreSQL 19, originally scheduled for official release on October 29, would be postponed to November 19. Prior to this, the project will introduce an additional Release Candidate 2 (RC2), scheduled for release on November 12. The official reason given is the high volume of fixes recently merged into various maintenance branches; the team wishes to first allow the community to verify these fixes via RC2 before proceeding to the final release.
Meanwhile, since the start of the Beta phase, approximately 8–10 significant features have been withdrawn from PostgreSQL 19, with some removed at a relatively late stage. While it is not uncommon for a major PostgreSQL version cycle to experience one significant feature rollback, withdrawing nearly 10 features clearly exceeds convention.
Peter Eisentraut, a PostgreSQL core committer and Vice President at EDB, subsequently wrote an article explaining this anomaly. One key variable identified was the rapidly maturing landscape of LLM-assisted code review and fuzz testing.
AI Uncovered Issues That Previously Took Five Years to Find
Peter Eisentraut dismissed a common speculation: these issues were largely not caused by "vibe coding."
He explained that most of the affected features, which were ultimately withdrawn, had been completed well before LLM-assisted programming and code review became mature. In other words, developers did not rely heavily on models like Claude or Codex to generate poor-quality PostgreSQL code that then exploded during the Beta phase. Instead, increasingly powerful AI review tools began re-examining code developed through traditional workflows.
Peter categorized the discovered issues into two main types. The first type was indeed severe: some withdrawn features contained architectural flaws that were difficult to thoroughly fix within the short timeframe of the Beta phase. Beyond this, a series of long-tail issues emerged: numerous problems that, while individually minor, only triggered under specific edge conditions.
In the past, such issues might not have been detected before release. PostgreSQL would typically ship as planned, and patches would gradually address these rare combinations as real-world users encountered them over the next few years. Peter estimates that many of these issues would likely have surfaced gradually over the next five years.
LLMs changed this process. With AI-assisted code review, edge-case defects previously scattered across several years can now be swept up in days or weeks.
Peter provided an example: developers suddenly faced around 40 bug reports. Even if each issue required an average of only three lines of code change, handling each one still incurred fixed overhead costs. Consequently, while the actual code changes might take only minutes, the cumulative effort across dozens of issues quickly exhausted human resources.
This led to a counterintuitive result: AI improved software quality but may have temporarily slowed down software release velocity.
Peter summarized this phenomenon as raising the "effective quality bar." When these features were originally developed and submitted, the industry lacked today's LLM review capabilities. By the time PostgreSQL 19 was preparing for release, new tools could detect issues that were previously hard to find. Code that might have met release standards under old criteria suddenly appeared "insufficient" under the new review capabilities.
AI-Assisted Fuzz Testing May Directly Enter Feature Development
Databases are particularly susceptible to this type of problem.
A key characteristic of PostgreSQL is that developers often expect different features to combine freely. An SQL feature must not only work in standard scenarios but may also be embedded within domains, composite types, partitioned tables, views, security-definer functions, triggers, and various other contexts, with these capabilities further nesting within each other.
Peter illustrated this with an example: a new SQL-level feature might need to handle combinations such as a domain nested within a composite type, where fields within that composite type are themselves domains; domains with non-null constraints; columns that were dropped and re-added; table partitions detached and then attached with different column orders; and finally, all of this appearing within a view called from a security-definer function inside a trigger.
Theoretically, developers want all these combinations to work correctly. However, humans struggle even to enumerate all possible combinations, let alone manually test each one.
LLM-assisted fuzz testing excels precisely at this kind of task. Models can continuously generate edge-case combinations, construct test inputs, observe anomalies, and expand along anomalous paths. Peter therefore judges that this type of AI-assisted fuzz testing will likely need to integrate directly into PostgreSQL's feature development workflow, rather than being concentrated solely in the late Beta stages.
Signs of this shift are already visible in actual development processes. In August of this year, PostgreSQL community member Robert Haas used Claude to assess the risk level of PostgreSQL 19 patches based on the number and types of bugs fixed after the feature freeze. SQL Property Graph Queries (SQL/PGQ) were listed as one of the high-risk features, having already undergone 17 fixes at that point.
Core developer Tom Lane subsequently stated that if SQL/PGQ entered PostgreSQL 19 in its current state, he would be willing to "bet dinner" that post-release issues would emerge that could only be fully resolved in PostgreSQL 20. Ultimately, SQL/PGQ was indeed withdrawn from PostgreSQL 19.
Another PostgreSQL community member later mentioned that initiating an AI review of the feature uncovered additional serious issues, which were then confirmed manually. This indicates that during this release cycle, AI was not merely acting as a "chat-style code commentator" but had begun participating in genuine risk screening for open-source projects.
However, Peter also emphasized that AI was not the sole reason for this large-scale rollback. Some of the code itself suffered from quality and architectural design issues. Additionally, the PostgreSQL community went through an intense period of security fixes this year; senior developers were heavily occupied with patching vulnerabilities from April to August, which impacted the additional reviews and testing originally scheduled for the early Beta phase. By the time these developers returned their focus to PostgreSQL 19, many issues had only surfaced late in the release cycle. Furthermore, the continuously growing complexity of PostgreSQL itself remains a fundamental underlying problem.
The sheer volume of issues ultimately forced the PostgreSQL community to make a rather conservative decision.
According to Peter, depending on how they are counted, approximately 8–10 major features have been pulled from the PostgreSQL 19 branch. Many of these are expected to be reintroduced in PostgreSQL 20 after being fixed. One representative example is SQL/PGQ, which allows querying property graph data composed of nodes and edges according to the SQL standard. However, due to unresolved issues, it failed to make it into PostgreSQL 19.
Notably, the PostgreSQL community previously considered the possibility that PostgreSQL 20 might primarily be a bug-fix release with few new features. The situation has now reversed: the batch of features removed from PostgreSQL 19 has effectively left a pool of nearly completed candidate features ready for PostgreSQL 20.
PostgreSQL 19 itself will not become a "minor version" because of this. Peter mentioned that it will still include significant capabilities such as REPACK CONCURRENTLY, logical replication for sequences, and query planner hints via pg_plan_advice. After undergoing this extra round of scrutiny, he actually expects PostgreSQL 19 to be a more robust release.
RC1 proceeded as planned on October 15, but the final release has been postponed from the original date of October 29 to November 19. The release team added RC2 on November 12, aiming to subject the accumulated recent fixes to another round of validation. Officials described this year as an "unusual major release cycle," emphasizing that the ultimate goal remains ensuring the stability and reliability of PostgreSQL.
If AI Finds Infinite Issues, How Much Should Humans Fix?
This incident quickly sparked discussion in the developer community. Many developers believe that the new bottleneck in software development may be shifting from "finding bugs" to "triaging bugs."
"This situation won't disappear anytime soon. The next real challenge is how to categorize issues found by AI, prioritizing only the most severe ones for human review," noted one developer. Others pointed out that when the cost of finding vulnerabilities and constructing anomalous inputs suddenly drops, the speed of "finding problems" no longer matches the speed of "fixing them." Previously, a security researcher might take days or even weeks to find a complex defect, whereas AI can explore numerous paths simultaneously, while human maintainers still have to verify them one by one.
Another group of developers worries that AI will cause an "influx of true and false bugs."
One developer shared their experience: AI often reports issues that seem reasonable in the context of local code but do not hold up when viewed within the entire system's context. If development teams mechanically fix every AI suggestion, they may end up with an over-engineered, less efficient system. The truly time-consuming part is for humans to judge item by item whether it is a real bug, an extreme but acceptable edge case, or a pure false positive.
A data engineering developer stated that in their internal AI code review system, even when the model has access to context from the code repository, Confluence, and JIRA, only about one-eighth of the reports are ultimately deemed valid. For more general-purpose review bots, this ratio could drop even further. Another developer familiar with static analysis tools noted that high volumes of false positives have always been an old problem with automated analysis. Once defect reports accumulate to the scale of hundreds of thousands, requiring humans to achieve 100% verification is virtually unrealistic.
However, some users have demonstrated through personal experience that despite dissatisfaction with false positives, they are unwilling to abandon AI reviews because they genuinely uncover technical debt hidden for years. They once conducted a centralized code review using AI on scripts, tasks, and configurations in a client system that had been running stably for about 10 years. The result was the discovery of 39 issues, 30 of which were confirmed as real bugs that had simply never been triggered before.
Similar situations are not limited to open-source projects like PostgreSQL. In some closed-source software, features developed over many years are starting to miss their original release schedules due to newly discovered issues flagged by LLMs. The past approach might have been to launch first and then apply patches in future versions. But once a development team is explicitly aware that a bug or theoretical vulnerability exists, carrying it into a formal release becomes increasingly difficult to justify from both security and liability perspectives.
Developers have pointed out that many issues in complex infrastructure software like databases cannot be solved simply by throwing bug reports back to an LLM and clicking "auto-fix." Some defects correspond to trade-offs in architecture and product semantics: a certain behavior might be a bug in Scenario A, a reasonable design in Scenario B, and imply that the foundational design from a year ago needs to be redone in Scenario C. AI can cheaply identify these contradictions, but deciding "what the correct behavior actually is" still requires experienced maintainers.
There are even concerns about reaching another extreme: "release paralysis." If AI can continuously dig up new edge cases from any complex codebase, theoretically, there will always be a next bug. Determining exactly how much needs to be fixed before a project is allowed to release may become a harder problem in the future than "how many bugs AI can find." Some developers suggest that instead of trying to eliminate all AI-discovered defects in a single version, they should be systematically registered, graded, and incorporated into subsequent development roadmaps. Otherwise, no large-scale software can ever reach a true state of "zero defects."
Conclusion
As coding capabilities of tools like Claude Code and Codex grow stronger, having AI write code is no longer a problem. The PostgreSQL 19 incident demonstrates that when AI is equally capable of large-scale code review, testing, and attack simulation, "finding problems" is also no longer a problem.
What may become truly scarce next is human judgment: Which issues must be fixed, and which are acceptable? Is an edge-case defect fixable in three lines of code worth delaying a major feature? Among the dozens of issues raised by AI, which ones indicate that the architecture itself needs redesigning? And when machines can endlessly search for anomalies, what level of quality does a piece of software need to reach to be considered "good enough to release"?
Reference links:
https://www.postgresql.org/message-id/f161fbb7-e193-42eb-bec7-4cfc1af74a50%40postgresql.org
https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves
https://www.postgresql.org/message-id/646368.1787697184%40sss.pgh.pa.us