AI 代码审查发现错误多于开发人员可以修复的情况后，PostgreSQL 19 推迟到 11 月发布
在 LLM 辅助代码审查发现的缺陷多于开发人员无法修复的缺陷后，PostgreSQL 19 GA 移至 11 月 19 日。删除了什么、保留什么以及如何计划升级。
新闻报道
发生了什么
PostgreSQL 19 不会按预期发布。该版本原定于 2026 年 9 月底或 10 月初发布。该项目现在表示 应于 2026 年 11 月 19 日全面发布，“除非发现需要延迟或额外发布候选版本的问题。”第一个候选版本 RC 1 于 10 月 15 日发布。第二个候选版本 RC 2 计划于 11 月 12 日发布。
图片： 达米恩来自维基共享资源，CC BY-SA 3.0 DE。
原因就是这个新闻。根据 PostgreSQL 的长期提交者 Peter Eisentraut 的说法，LLM 辅助的代码审查发现新功能中的缺陷的速度比项目开发人员修复它们的速度要快，而且发布团队提取了大约 8 到 10 个重要功能，而不是只修复了一半。 登记册 10 月 16 日报告了延误。
人工智能审核通常被视为一种加快交付速度的方式。在这里却做了相反的事情。
为什么AI审核会减慢发布速度
Eisentraut 在 10 月 9 日的一篇题为“ “恢复将继续下去，直到士气提高。” PostgreSQL 的设计承诺是功能组合。 “我喜欢说，在 PostgreSQL 中，‘一切都适用’，”他写道，用户期望奇怪的组合能够发挥作用。新功能必须与分区、触发器、复制和其他所有功能一起运行，没有人可以手动枚举这些组合，更不用说测试它们了。
LLM 审阅者可以生成它们。 “通过 LLM 辅助的代码审查，可以更快地发现此类问题，然后你就会盯着大约 40 个缺陷报告的列表，”Eisentraut 写道。大多数问题都是《登记册》所总结的“涉及各种边缘情况的相对无害的问题”。一件一件的都很便宜。它们加在一起就不是这样了：“即使每个问题平均只需要三行修复，处理每一个问题都会有固定的开销，然后你就会耗尽时间。”
每个报告仍然需要人工来复制、判断、编写修复程序、审查修复程序并提交。发现错误的成本下降了。关闭一个的成本却没有。
人工智能并不是唯一的因素。 Eisentraut 表示，大约从 4 月到 8 月，“Vulnpocalypse”让许多高级开发人员忙于安全修复，这段时间通常是进行 Beta 审查和测试的时间。更少的人力会遇到更长的缺陷清单。对于一些恢复的功能，报告还暴露了难以“在测试期间快速”修复的架构缺陷。
的 PostgreSQL 19 未清项目 wiki 显示了规模：在 beta 1 和候选版本之间解决了 180 多个项目，当我们在 2026 年 10 月 19 日检查时，仍有少数项目尚未解决。
从 PostgreSQL 19 中提取的内容
最明显的受害者是 SQL 属性图查询 (SQL/PGQ)，这种图查询语法于 2023 年进入 SQL 标准，并通过 GRAPH_TABLE 条款。 Tom Lane 是该项目服务时间最长的贡献者之一，他曾在 9 月份反对将其发回：“在这一点上，我愿意打赌，如果我们在 v19 中发布它，那么在发布后会发现无法修复的错误，直到 v20。”它没有出现在 19 版发行说明中。
图片： 内维特·迪尔门（Nevit Dilmen）来自维基共享资源，CC BY-SA 3.0。
Open Items wiki 记录了其他的恢复，包括离线数据校验和更改、时间的剩余部分 FOR PORTION OF 工作， MERGE PARTITIONS 和 SPLIT PARTITIONS, 的 pg_get_*_ddl() 函数（发回重新设计）和非普通输出格式 pg_dumpall。将其视为来自 wiki 的示例而不是官方列表。 Eisentraut 自己的统计是“大约”8 到 10 个显着特征。
PostgreSQL 19 中还有什么
“PostgreSQL 19 仍然会是一个很棒的版本，”Eisentraut 写道，“经过所有额外的审查，它将非常强大。”的 发行说明 支持他为任何在生产环境中运行 Postgres 的人提供支持。
图片： 凯尔蒂来自维基共享资源，CC BY-SA 4.0。
标题是 REPACK，一个回收磁盘空间并重新组织表的新命令。 REPACK (CONCURRENTLY) 在不阻塞读取或写入的情况下完成此任务，如今许多团队将这项工作交给了 pg_repack 扩展。尽管 RC 1 仍然对其进行了一些修复，但它在淘汰中幸存下来。
复制丢失了两项操作任务。现在可以在以下情况下打开逻辑复制而无需重新启动服务器 wal_level 设置为 replica，并且序列值进行逻辑复制，因此逻辑复制切换不再以手动序列重新同步结束。一个新的 WAIT 命令在备用数据库上提供读你所写的一致性。
Planner 控制通过 pg_plan_advice 扩展实现，并使用 pg_stash_advice 自动应用该建议。 Autovacuum 可以并行处理表的索引，并通过新的评分系统决定首先清理哪些内容。 I/O 工作进程自动扩展，外键检查速度更快。
RC 1 本身发生了一项行为变化： COPY (query) TO ... (FORMAT json) 现在使用查询的列名（包括别名）作为 JSON 键。如果您测试了 JSON 输出 COPY 在测试版上，再次测试。
这对您的升级计划意味着什么
计划在 10 月份进行升级的团队应该将其推迟大约七周。现在针对 RC 1 进行测试。 11 月 12 日在 RC 2 上重新测试，该版本与受支持分支的更新发布同一天发布；发布团队正在 GA 之前将该版本的大量修复合并为 19 个。将制作安排在 11 月 19 日之后，并且只有在该日期实际满足后才进行制作。来自任何早期的主要版本仍然意味着 pg_upgrade 或 pg_dump 和 pg_restore，作为 RC 1 公告 笔记。
图片： PgAdmin Ueberblick 来自维基共享资源。
如果您正在等待 SQL/PGQ 淘汰单独的图形数据库，请保留该图形数据库。恢复的功能现在针对 PostgreSQL 20，但没有日期。 Eisentraut 表示很难预测，几个月前他建议 20 个“可能没有新功能，只是修复了错误”。现在，它有大量的返回功能需要吸收，每一项都将满足相同的法学硕士辅助审查。
对于任何在人工智能审阅者参与下交付软件的人来说，这都是一个教训。 PostgreSQL 19 中的边缘情况以前就存在过；不同的是，现在有人可以在一个下午的时间内列出它们。瓶颈从发现错误转变为修复错误，一个在贡献者有限的时间内运行的项目首先感受到了这一点。