PostgreSQL 19 推迟至 2026 年 11 月，LLM 代码审查迫使 8-10 个功能回退

PostgreSQL 19 已推迟至大约 2026 年 11 月 19 日，并且有 8 到 10 个重要功能已从该版本中移除，因为 LLM 辅助的代码审查发现的缺陷数量超过了项目的人类提交者在截止日期前能够分类和修复的数量。PostgreSQL 全球开发组将回退归因于周期中途提高的质量标准，而非 AI 编写的代码。

PostgreSQL 19 从 2026 年 9 月底/10 月初推迟至大约 2026 年 11 月 19 日

PostgreSQL 全球开发组将 PostgreSQL 19 从原定的 2026 年 9 月底或 10 月初的目标推迟到预计的通用可用日期大约 2026 年 11 月 19 日。伴随推迟，开发人员从该版本中移除了 8 到 10 个重要功能，将其推迟到 PostgreSQL 20。

Peter Eisentraut，一位领先的 PostgreSQL 提交者及 EDB（一家 PostgreSQL 支持和咨询公司）的副总裁，将异常多的回退至少部分归因于开发人员运行的 LLM 代码审查。

LLM 辅助审查在功能已提交后提高了质量标准

Eisentraut 的解释，发表于 2026 年 10 月 9 日的一篇题为 "The reverts will continue until morale improves" 的博客文章中，将回退的工作分为两类。

第一类是真正的架构缺陷。一些回退的功能存在重大的架构问题，这些问题在“快速且处于测试阶段”时很难修复。

第二类是长尾问题。LLM 辅助的代码审查发现了许多“涉及各种边缘情况的相对无害的问题”，在以前的周期中，开发人员可能要到很晚才会注意到这些问题——通常会在发布后的五年内以错误修复的形式出现。Eisentraut 描述了由此产生的工作量：

“借助 LLM 辅助的代码审查，这类问题可以更快地被发现，然后你会面对一份包含四十个缺陷报告的列表。即使每个缺陷平均只需要三行代码的修复，处理每个缺陷都有固定的开销，然后时间就不够了。”

时间问题在于，PostgreSQL 19 的主要功能是在 LLM 辅助代码审查能力不如现在的时候编写的。审查工具在发布前的几个月内得到了改进，而代码已经提交。Eisentraut 将此视为一次性的不匹配：

“有效的质量标准在功能编写和提交之后被提高了。除非 LLM 辅助代码审查的能力继续以当前速度提升，否则这种情况在未来的开发周期中应该会自行解决。”

根据 PostgreSQL 提交者的说法，回退并非“氛围编码”

Eisentraut 明确否定了 AI 生成的代码导致回退的解释。他表示，回退并非由于开发中的“氛围编码”，因为该技术在大多数新功能编写时并不可用。缺陷是由 AI 审查人类编写的代码发现的，而非 AI 编写引入的。

SQL/PGQ 是从 PostgreSQL 19 中移除的功能之一

从 PostgreSQL 19 中移除的功能之一是 SQL 属性图查询（SQL/PGQ）的支持，该功能于 2023 年成为 SQL 标准的一部分。SQL/PGQ 提供了探索由边连接的节点之间关系的语法。PostgreSQL 的实现因未解决的问题而被移除。

PostgreSQL 贡献者 Tom Lane 在回退之前曾对该功能发出警告。在 2026 年 9 月，他表示：

“在这一点上，我愿意打赌，如果我们把它发布在 v19 中，将会在发布后发现无法在 v20 之前修复的错误。”

PostgreSQL 19 仍然提供 REPACK CONCURRENTLY，并预计将是稳健的

尽管有延迟和回退，Eisentraut 表示 PostgreSQL 19 仍将是一个“伟大的版本”。一个确认的亮点是 REPACK CONCURRENTLY，它避免了用于回收磁盘空间的表锁 VACUUM FULL 操作。他还认为额外的审查带来了好处：“经过所有额外的审查，它将非常稳健。”

回退的功能现在预计将在 PostgreSQL 20 中落地

从 PostgreSQL 19 回退的功能可能会进入 PostgreSQL 20。这推翻了仅几个月前宣布的计划：开发人员曾预计 PostgreSQL 20 将不包含新功能，只包含错误修复。PostgreSQL 20 现在很可能包含早期版本遗留的新功能。

PostgreSQL 的历史解释了为什么项目在发布方面持保守态度

PostgreSQL 最初由 Michael Stonebraker 于 1986 年提出。1994 年，Andrew Yu 和 Jolly Chen 用 SQL 替换了查询语言 POSTQUEL，1995 年，该数据库在更宽松的许可证下免费提供和修改，并更名为 PostgreSQL。此后，它成为专业开发人员中最受欢迎的数据库，这得益于三大超大规模云服务商构建的服务以及可用的有线兼容分布式系统。

评论者认为 QA 是 AI 时代的瓶颈，而非编码

Hacker News 上关于延迟的讨论集中在一个主题上：AI 使缺陷发现变得廉价，而缺陷解决变得昂贵，这使得质量保证成为发布计划的约束。

一位评论者认为，AI 审查发现的错误不是那种可以通过按钮按下就能修复的，因为它们需要设计判断：

“我的一些猜测是，发现的错误不是那种你可以直接按下 LLM 按钮就能修复的，而是那种需要审查者深入考虑设计权衡的错误，我相信在数据库或编程语言代码库中这类错误更多。”

另一位评论者将这种转变描述为失去合理的否认：一旦工具能够全面发现错误和缺失的测试用例，团队就不能再发布简陋的功能并推迟后果。结果是每个功能花费更多时间，发布看起来效率更低，尽管实际上更好。

第三位评论者提出，QA 是持久价值所在：

“在 AI 时代，QA 正在成为项目的瓶颈，也是真正的价值来源。AI 可以打下良好的测试基础，但我看到即使是前沿模型在测试方面仍然需要帮助，因为它们在测试方面基本上和人类一样糟糕，只测试想到的内容，甚至可能更差一点。”

同一位评论者认为，这巩固了 SaaS 而不是杀死它，因为一个能够通过提示生成前端系统的小企业仍然不会想要对其进行 QA——而且 QA 负载随着代码量的增加而增加。与 PostgreSQL 的比较是直接的：“即使你今天可以提示生成一个数据库，你也不能提示生成一个像 Postgres 那样经过测试和 QA 的东西。”

反驳：AI 可以找到几乎无限多的错误

讨论中一个反复出现的反对意见是，AI 审查没有自然的停止点。正如一位评论者所说，“AI 确实可以找到无限多的错误。总有更多的错误可以被发现，无论它们是否会影响任何实际现实世界的情况或被注意到。”

这引出了另一位评论者提出的明显问题：如果当前版本有这么多潜在错误，那么已经投入生产的版本也是如此。“这难道不意味着现有版本的 Postgres 也可能有比人类能修复的更多的错误吗？直接发布吧。软件永远不会完美，总是在进行中。”

反驳：AI 错误报告仍需要人工分类

几位评论者警告说，原始的 AI 输出不是缺陷列表。一位评论者引用了之前的一个案例，其中 AI 工具报告了 Linux 内核中的 82 个错误，但只有 6 到 8 个被证明是真实的——其余要么已经修复，要么在新版本中已修复，要么是捏造的。得出的结论是：在人类筛选之前，怀疑是必要的。

其他人则将同样的观点作为流程规则而不是停止的理由：

“使用 AI 来发现错误（而不是编写错误）在我看来是一个很好的用例。即使你有熟练的审查者，更多的眼睛几乎总是更好。只是请不要把未经编辑的 AI‘错误报告’作为问题发布。人类应该确保它确实是一个真正的问题，然后再把它扔给开发人员。”

一位评论者还指出了框架中的潜在利益冲突，指出 Eisentraut 的雇主 EDB 销售面向 AI 的 Postgres 产品，并反问在 AI 之前 PostgreSQL 中是否从未有过任何有效的东西。

更深层的说法：PostgreSQL 的测试套件，而非 AI，是根本原因

一位从事 PostgreSQL 的 Rust 重写的评论者提供了技术上最具体的反叙事：AI 并没有创造错误，而是在暴露一个从未设计用于处理边缘情况的测试套件。

“在大多数情况下，Postgres 依赖单独的回归测试来测试每个功能。虽然回归测试对于确保功能不破坏很好……但它们实际上并不擅长处理边缘情况（向特定函数传递超过 2MB 的字符串将触发缓冲区溢出并导致数据库崩溃）。”

该评论者报告在构建重写时在核心 PostgreSQL 中发现了大约 50 个错误，使用 AI 来扩展早于 AI 的技术——确定性模拟测试、差分覆盖引导的模糊测试和形式验证。最激进的例子：一个将 C 和 Rust 函数翻译成 Lean 的编译器，LLM 编写证明两个实现相同的证明。在撰写本文时，代码库的 10.5%（640k 行中的 67k 行）已被验证为等价，发现的问题细粒度到解析函数，其中 PostgreSQL 使用 isspace() 修剪空格，而重写仅修剪 ASCII 空白。

PostgreSQL 19 延迟对 AI 辅助工程的启示

PostgreSQL 19 的延迟是一个早期、具体的例子，表明一种模式可能会在成熟的开源项目中重复出现：AI 审查降低发现缺陷的成本远快于降低解决缺陷的成本，因此约束从编写代码转移到裁决发现。PostgreSQL 的回应——将功能回退到下一个主要版本，而不是发布已知有缺陷的工作——是保守的选择，并且符合该项目长期以来的实践，即最小化风险变更并依赖大量人工审查。

Eisentraut 自己的预测是，这种影响是过渡性的：不匹配的存在只是因为审查能力在代码编写后得到了改进。如果 LLM 审查能力继续以当前速度提升，未来的开发周期将从一开始就在新的质量标准下编写，而不是事后适应。