近日，PostgreSQL 19 的发布出现罕见波折。PostgreSQL 团队宣布，原计划于 10 月 29 日正式发布的 PostgreSQL 19，将推迟至 11 月 19 日。在此之前，项目还将额外增加一个 RC2 候选版本，于 11 月 12 日发布。官方给出的原因是，近期被加入各维护分支的修复数量较多，希望先通过 RC2 将这些修复交给社区验证，再进入正式发布。
与此同时，在 Beta 阶段开始后，大约有 8～10 项重要功能被从 PostgreSQL 19 中撤回，其中部分功能是在相当靠后的阶段才被移除。正常情况下，一个 PostgreSQL 大版本周期出现一项重要功能回滚并不罕见，但一次撤回接近 10 项，已经明显超出了惯例。
PostgreSQL 核心提交者、EDB 副总裁 Peter Eisentraut 随后专门撰文解释了这次异常，其中一个关键变量，正是迅速成熟起来的大模型辅助代码审查和模糊测试。
AI 把以前 5 年才能发现的问题提前翻了出来
Peter Eisentraut 否定了一个很容易出现的猜测：这些问题大体上并不是 vibe coding 造成的。
他解释道，大多数受到影响并最终被撤回的功能，早在 LLM 辅助编程和代码审查成熟之前就已经完成。也就是说，并不是开发者让 Claude、Codex 等模型大量生成了质量不佳的 PostgreSQL 代码，然后在 Beta 阶段集中爆雷；相反，是后来越来越强的 AI 审查工具，开始重新检查此前按照传统流程开发出来的代码。
Peter 将被发现的问题大致分为两类。第一类确实比较严重，一些被撤回功能存在架构层面的缺陷，在 Beta 阶段短时间内很难彻底修正。但除此之外，还出现了一系列长尾问题：大量单独看并不严重、只会在特定边缘条件下触发的问题。
过去，这类问题可能不会在发布前被发现。PostgreSQL 会先正常发布，然后在未来几年里随着真实用户撞上各种罕见组合，再一点点补丁修复。Peter 估计，其中不少问题原本可能要在接下来的 5 年内逐渐浮现。
LLM 改变了这个过程。借助 AI 辅助代码审查，过去分散在数年时间里的边缘缺陷，现在可能在几天或几周内被集中扫出来。
Peter 举例道，开发者突然面对大约 40 份缺陷报告，即便每个问题平均只需要改 3 行代码，但处理每一个问题仍然需要固定成本，于是代码本身可能只改几分钟，但几十个问题叠加起来，人类的时间很快就被耗尽。
这也导致了一个非常反直觉的结果：AI 提高了软件质量，却可能在短期内降低软件发布速度。
Peter 将这种现象概括为“有效质量门槛被抬高了”。这些功能当初被开发和提交时，行业还没有如今这样的 LLM 审查能力；等到 PostgreSQL 19 准备发布时，新的工具已经可以发现过去难以发现的问题。原本可能符合发布标准的代码，在新的审查能力下突然“不够好了”。
AI 辅助模糊测试或可直接进入功能开发
数据库尤其容易遭遇这种问题。
PostgreSQL 的一个重要特点是，开发者往往期待不同功能能够自由组合。一个 SQL 功能不仅需要在最普通的情况下运行，还可能被放进 domain、复合类型、分区表、视图、安全定义函数、触发器等各种环境里，并且这些能力还能继续互相嵌套。
Peter 举例称，一个 SQL 层面的新功能可能需要面对这样的组合：domain 套在复合类型上，复合类型里的字段本身又是 domain；domain 带有非空约束；列曾被删除又重新添加；表分区被 detach 后又按照不同列顺序 attach；最终这一切又出现在一个视图里，而这个视图从触发器中的 security-definer 函数被调用。
理论上，开发者希望这些东西全部正常工作，问题在于人类甚至很难枚举出所有组合，更不用说逐个手工测试。
LLM 辅助模糊测试恰好非常擅长这一类工作。模型可以不断生成边缘组合、构造测试输入、观察异常，再继续沿着异常路径扩展。Peter 因此判断，这类 AI 辅助模糊测试未来很可能需要直接进入 PostgreSQL 的功能开发流程，而不能等到 Beta 后期才集中使用。
实际开发过程已经出现类似迹象。今年 8 月，PostgreSQL 社区成员 Robert Haas 曾让 Claude 根据 feature freeze 之后修复的 Bug 数量和类型，对 PostgreSQL 19 的补丁进行风险评估。其中 SQL 属性图查询被列为高风险功能之一，当时已经经历 17 次修复。
核心开发者 Tom Lane 随后表示，如果 SQL/PGQ 按当时状态进入 PostgreSQL 19，他甚至愿意“赌一顿晚饭”，认为发布后还会发现只能等到 PostgreSQL 20 才能彻底解决的问题。最终，SQL/PGQ 确实从 PostgreSQL 19 被撤回。
另一名 PostgreSQL 社区成员随后也提到，对该功能启动 AI 审查之后，又发现了一些严重问题，并进行了人工确认。这意味着在这次发布周期中，AI 并不仅仅充当“聊天式代码评论员”，而是已经开始参与真实开源项目的风险筛查。
不过，Peter 也强调，AI 并不是这次大规模撤回的唯一原因。部分代码自身质量和架构设计确实存在问题，今年 PostgreSQL 社区还经历了一轮密集安全问题处理，大量资深开发者从 4 月到 8 月都在忙于修复安全问题，导致 Beta 前期原本应该进行的额外评审和测试受到影响。等这些开发者重新投入 PostgreSQL 19 时，许多问题已经到了发布周期后段才暴露出来。此外，PostgreSQL 自身持续增长的复杂性也是根本问题之一。
大量问题最终迫使 PostgreSQL 社区做出了相当保守的决定。
Peter 称，根据统计方式不同，大约有 8～10 项重要功能已经从 PostgreSQL 19 分支撤回，其中不少预计将在修正后重新进入 PostgreSQL 20。其中一个代表性功能就是 SQL/PGQ，它用于按照 SQL 标准查询由节点和边组成的属性图数据，但由于仍存在未解决的问题，最终未能进入 PostgreSQL 19。
值得注意的是，PostgreSQL 社区此前甚至一度认为 PostgreSQL 20 可能主要用于修 Bug，不会有太多新功能；现在情况反了过来：PostgreSQL 19 撤下的一批功能，反而已经为 PostgreSQL 20 留下了一批接近完成的候选功能。
PostgreSQL 19 本身也并非因此变成一个“小版本”。Peter 提到，其中仍将包括 REPACK CONCURRENTLY、序列的逻辑复制，以及通过 pg_plan_advice 实现的查询规划器提示等重要能力。在经历这轮额外审查之后，他反而预计 PostgreSQL 19 会成为一个更加稳健的版本。
RC1 已按计划于 10 月 15 日推进，但正式版从原定 10 月 29 日推迟至 11 月 19 日。发布团队还新增了 11 月 12 日的 RC2，希望让近期积累的大量修复再经历一轮验证。官方将今年称为一个“不寻常的大版本发布周期”，并强调最终目标仍然是保证 PostgreSQL 的稳定性和可靠性。
AI 无限发现问题，那人类该修到什么程度？
这件事随后在开发者社区迅速发酵，不少开发者认为，软件开发新的瓶颈可能正在从“发现 Bug”转移到“给 Bug 分类”。
“这种情况不会很快消失，下一步真正需要解决的是如何对 AI 找出来的问题进行分类，只把最严重的问题优先送到人工审查。”另一些开发者也指出，当找漏洞和构造异常输入的成本突然下降之后，“发现问题”和“修复问题”的速度已经不再匹配。以前安全研究者找到一个复杂缺陷可能需要几天甚至几周，而 AI 可以同时探索大量路径，人类维护者却仍然只能一个一个确认。
但另一派开发者担心的是，AI 会造成“真假 Bug 泛滥”。
有开发者表示，自己的经验是 AI 会报告大量从局部代码看似合理、放到整个系统语境中却并不成立的问题。如果开发团队机械修复每一个 AI 建议，最终可能得到一个过度设计、效率更差的系统。真正费时间的地方是人类必须逐项判断究竟是真 Bug、极端但可以接受的边缘情况，还是纯粹的误报。
一名从事数据工程的开发者称，在其内部 AI 代码审查系统中，即便模型能够访问代码仓库、Confluence 和 JIRA 等上下文，大约也只有八分之一的报告最终被认为有效；对于更通用的审查机器人，这一比例甚至可能进一步下降。另一名熟悉静态分析工具的开发者则表示，大量误报一直都是自动化分析的老问题，一旦积累到十万级缺陷报告，要求人工做到 100% 确认几乎不现实。
不过，有用户也以自身经历为例证明了，即便对误报不满仍然不愿意放弃 AI 审查，因为它确实能够把隐藏多年的技术债翻出来。他们曾让 AI 对一个已经稳定运行约 10 年的客户系统中的脚本、任务和配置进行集中代码审查，最终发现 39 个问题，其中 30 个被确认是真实 Bug，只不过此前从未被触发。
类似事情并不仅仅发生在 PostgreSQL 这样的开源项目中。一些闭源软件里，开发多年的功能同样开始因为 LLM 新发现的问题而无法按原计划发布。过去的做法可能是先上线，再在未来版本逐步补丁；但一旦开发团队已经明确知道某个 Bug 或理论漏洞存在，继续把它带进正式版本，在安全和责任层面都会变得越来越难解释。
有开发者指出，数据库这类复杂基础软件中的很多问题，并不是把 Bug 报告重新扔给 LLM，然后点击“自动修复”就能解决。一些缺陷实际上对应的是架构和产品语义上的取舍：某一种行为在使用场景 A 下可能是 Bug，在场景 B 下可能是合理设计，换到场景 C 又可能意味着一年前的基础设计本身需要重做。AI 可以非常便宜地把这种矛盾找出来，但决定“正确行为究竟是什么”依然需要经验丰富的维护者。
甚至已经有人担忧出现另一种极端：“发布瘫痪”。如果 AI 可以不断从任何复杂代码库里继续挖出新的边缘问题，那么理论上永远存在下一个 Bug。项目究竟应该修到什么程度才允许发布，未来可能成为比“AI 能找到多少 Bug”更困难的问题。有开发者建议，与其追求在单个版本里消灭所有 AI 找出的缺陷，不如把它们系统化登记、分级，纳入后续开发路线，否则没有任何大型软件能够达到真正意义上的“零缺陷”。
结束语
Claude Code、Codex 等工具的编码能力越来越强后，AI 写代码已经不是问题，而 PostgreSQL 19 事件展现出了，当 AI 同样能够大规模审查、测试和攻击代码之后，“发现问题”也不再是问题。
接下来真正稀缺的，可能变成人类的判断力：哪些问题必须修，哪些问题可以接受；一个三行代码能够修复的边缘缺陷，是否值得为它推迟一个重要功能；AI 给出的几十个问题里，哪几个意味着架构本身需要重新设计；以及当机器可以无休止地寻找异常时，一款软件究竟要达到什么程度，才算“足够好，可以发布”。
参考链接：
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
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
In recent days, publish of PostgreSQL 19 showed a rare turn. The PostgreSQL team announced that PostgreSQL 19, originally planned for 29 October, would be postponed until 19 November. Prior to this, the project will add an additional RC2 candidate version on November 12, publish. The official reason for this is the relatively high number of repairs that have recently been added to the maintenance branches, and it is hoped that they will be handed over to the community for validation before entering the official publish.
At the same time, after the beginning of the Beta phase, about 8-10 important functions were withdrawn from PostgreSQL 19, some of which were removed at a rather later stage. As a rule, it is not unusual for an important function to roll back in a large version of PostgreSQL cycle, but a withdrawal close to 10 items has clearly exceeded practice.
The postgreSQL core submiter, Peter Eisentraut, Vice-President of EDB, then wrote a special article explaining the anomaly, one of the key variables being the rapidly mature LLM subsidiary code review and fuzzy testing.
AI turned out the problems we had five years ago.
Peter Eisentraut rejects an easy speculation: these problems are largely not caused by vibe coding.
He explained that most of the functions affected and eventually withdrawn had been completed well before the LLM auxiliary programming and code review matured. In other words, the developers did not allow models such as Claude and Codex to generate poor-quality PostgreSQL codes in large quantities, and then concentrate on blasting at Beta stage; rather, the later and increasingly powerful AI review tool began to re-examine the previously developed codes from traditional processes.
Peter divided the problems identified into roughly two categories. The first category is indeed more serious, and some of the withdrawn functions are structurally flawed and are difficult to overhaul in a short period of time during the Beta phase. But beyond that, there are a number of long-term problems: a large number of problems that are not serious on their own and that can only be triggered under certain marginal conditions.
In the past, such problems may not have been detected before publish. PostgreSQL will start with normal publish, and then over the next few years, with real users crashing into rare combinations, a little patch. Peter estimates that many of these problems could have emerged over the next five years.
LLM changed the process. Through the AI support code review, the marginal defects, which had been dispersed over several years, could now be cleaned up in a few days or weeks.
Peter, for example, the developers suddenly faced about 40 shortcomings reports, even though each problem averaged only 3 lines of code, each problem still required fixed costs, so the code itself could be changed for only a few minutes, but dozens of problems were stacked together and human time was quickly exhausted.
This has also led to a very counterintuitive result: AI has improved the quality of the software but may reduce the speed of the software publish in the short term.
Peter summed up the phenomenon as “the threshold of effective quality has been raised”. When these functions were first developed and submitted, the industry did not have the current LLM review capability; by the time PostgreSQL 19 was ready for publish, the new tools would have discovered problems that were difficult to discover in the past. The code, which might have met the publish standard, was suddenly “not good enough” with the new vetting capability.
AI Auxiliary Fuzzy Test or Direct Accessible Functional Development
The database is particularly vulnerable to such problems.
An important feature of PostgreSQL is that developers often expect different functions to be assembled freely. A SQL function not only needs to be run in the most common circumstances, but may also be placed in a variety of environments such as domain, compound type, partition table, view, safe definition function, trigger, etc., and these capabilities can continue to be embedded in each other.
Peter, for example, a new function at the SQL level may need to face a combination of: domain in a composite type, where field itself is a domain; domain has a non-empty constraint; columns have been deleted and re-added; table partitions have been detached and then in different rows attach; eventually all of this appears in another view, which is called from the trigger 's security-definer function.
In theory, developers want all of this to work, and the problem is that it is difficult for humans to even list all the combinations, let alone hand-tested.
LLM auxiliary fuzzy tests happen to be very good at this type of work. Models can continuously generate peripheral combinations, construct test inputs, observe anomalies, and continue to expand along abnormal paths. Peter therefore concluded that such AI-assisted fuzzy testing would probably require a functional development process directly into PostgreSQL in the future, and could not wait until Beta post-production was centralized.
Similar signs have emerged in the actual development process. In August this year, Robert Haas, a member of the PostgreSQL community, asked Claude to carry out a risk assessment of the patches of PostgreSQL 19 based on the number and type of Bugs repaired after the feature freeze. Of these, the SQL attribute chart query was listed as one of the high-risk functions that had already been repaired 17 times.
The core developer, Tom Lane, then stated that if SQL/PGQ entered PostgreSQL 19 in its current state, he would even be willing to “take a bet” on dinner, believing that after publish, it would only wait until PostgreSQL 20. Eventually, SQL/PGQ did withdraw from PostgreSQL 19.
Another member of the PostgreSQL community subsequently mentioned that, following the launch of the AI review of the function, serious problems had been identified and human confirmation had been carried out. This means that in this publish cycle, AI is not just a chat code commentator, but has started to participate in the real open source project.
But Peter also stressed that AI was not the only reason for this massive withdrawal. There are real problems with the quality and architecture of some of the codes themselves, and this year the PostgreSQL community has also experienced an intensive security round, with a large number of senior developers working from April to August to repair security problems, which has affected additional reviews and tests that Beta should have carried out earlier. By the time these developers are reinvested in PostgreSQL 19, many of the problems are not revealed until after the publish cycle. Moreover, the complexity of PostgreSQL ' s own sustained growth is one of the fundamental issues.
Many problems eventually forced the PostgreSQL community to make rather conservative decisions.
According to Peter, some 8-10 important functions have been withdrawn from the PostgreSQL 19 branch, depending on the statistical pattern, and many of them are expected to be re-entered into PostgreSQL 20 after amendment. One of the representative functions is SQL/PGQ, which is used to query property map data consisting of nodes and sides according to SQL standards, but ultimately cannot enter PostgreSQL 19 due to unresolved issues.
It is worth noting that the PostgreSQL community had previously even thought that PostgreSQL 20 might be used mainly to fix Bugs, and that there would be little new functionality; the situation is reversed: PostgreSQL has withdrawn a number of functions, and has left a pool of near-completed candidate functions for PostgreSQL 20.
PostgreSQL 19 does not in itself become a small version. Peter mentioned that it will continue to include EREPACK CONCURRENTLY, logical copying of sequences, and important capabilities such as query planner tips achieved through pg plan advice. After this round of additional reviews, he was expecting PostgreSQL 19 to become a more robust version.
RC1 advanced as planned on 15 October, but the official version was postponed from 29 October to 19 November. The publish team also added a new RC2 on November 12th, hoping for another round of validation of the extensive repairs accumulated in the near future. Officially, this year will be known as an “unusual large version of the publish cycle” and will emphasize that the ultimate goal remains to ensure the stability and reliability of PostgreSQL.
AI finds the problem infinity. How far should we build it?
This was then rapidly fermented in the developers' community, and many felt that new bottlenecks in software development might be shifting from “discovering Bug” to “classification to Bug”.
“This situation will not disappear soon, and what next step really needs to address is how to classify the problems identified by AI and to give priority to the most serious ones to manual review.” Other developers also noted that the speed of “discovery problems” and “repair problems” was no longer matched when the cost of searching for loopholes and tectonic abnormalities fell suddenly. While previous security researchers may have found a complex flaw in a few days or weeks, AI can simultaneously explore a large number of paths, while human defenders still have only one confirmation.
But another developer fears that AI will create a "false and false Bug proliferation."
Some developers say that their experience is that AI will report a large number of issues that seem reasonable from local code and are not valid in the system context. If the development team mechanically fixes every AI proposal, a system that is too designed and less efficient may eventually be obtained. What really took time was whether human beings had to judge, on a case-by-case basis, whether they were true Bugs, extreme but acceptable margins or simply false statements.
According to one developer engaged in data engineering, in its internal AI code review system, even if the model had access to context, such as the code warehouse, Confluence and JIRA, only about one-eighth of the reports were ultimately considered valid; for more generic review robots, the proportion might even fall further. Another developer, familiar with static analysis tools, indicated that extensive misstatement has been an old problem of automated analysis, requiring a manual 100 per cent recognition of almost unrealistic once a 100,000-degree deficiency report has accumulated.
However, users have also demonstrated, using their own experience, that they are reluctant to give up the review of AI even if they are dissatisfied with false reporting, as it is indeed capable of reversing years of hidden technical debt. They had AI conduct a centralized code review of scripts, tasks and configurations in a client system that had been running for about 10 years, and eventually found 39 problems, of which 30 were confirmed to be true Bugs, but had never been triggered before.
Something like this does not just happen in open-source projects like PostgreSQL. In some closed-source software, the functionality that has been developed for many years has also begun to be unable to follow plan publish because of new problems discovered by LLM. The past approach may have been to go online before gradually patching up in future versions; but once the development team has become clear that a Bug or theoretical loophole exists, continuing to bring it into the official version will become increasingly difficult to explain at the security and accountability levels.
It was pointed out that many of the problems in complex basic software such as databases were not simply tossing Bug reports back to LLM, which could be solved by clicking on "auto-repair". Some of the deficiencies actually correspond to the symmetrical trade-offs in architecture and products: One behavior may be under scenario A, but under scenario B it may be a rational design, and moving to scenario C it may mean that the basic design itself needed to be reworked a year ago. AI can find this contradiction very cheaply, but deciding “what is the right act” still requires experienced defenders.
There are even fears of another extreme: “publish paralysis”. If AI can continue to dig new edges out of any complex code repository, then the next Bug is in theory forever. The extent to which the project should be built to allow publish could become more difficult in the future than what “AI can find in Bug”. It was suggested that instead of pursuing the elimination of all deficiencies identified by AI in a single version, they should be systematically registered, graded and included in the subsequent development route, without which no large software would be able to achieve a genuine “zero flaw”.
Concluding remarks
When tools such as Claude Code and Codex become more and more capable of coding, the AI writing code is no longer a problem, while the PostgreSQL 19 event shows that “discovering problems” is no longer a problem when AI is equally able to review, test and attack codes on a large scale.
What is really scarce then may become a human judgement: what must be repaired and what is acceptable; whether a three-line code can repair a marginal flaw that is worth postponing an important function for it; which of the dozens of questions AI has given means that the architecture itself needs to be redesigned; and what is the extent to which a software is “good enough to be able to publish” when the machine can search indefinitely for anomalies.
References:
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
Auto-fetched and translated by AI Atlas. All rights belong to the original author.