本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
搞软件的技术圈最近可忙了，天天“吃瓜”。新 AI 发布、漏洞、REA，再不就是烂尾延期等等。之前和 MySQL 对着干的全球最稳的开源数据库 PostgreSQL 19，官宣延期到 11 月 19 日发布了。不仅如此，还一口气撤回了 8 到 10 个已经开发完的重要功能。
要知道 8 到 10 个主要功能，算得上是半到一个大版本的功能集了。这差点就相当于整个 PostgreSQL 19 被团灭了。
PostgreSQL 19 烂尾始末
10 月 16 日，The Register 刊发了一篇标题相当抓人的报道，《Postgres 19 delayed after AI reviewers find more bugs than humans can fix》。这不是标题党，这个以“世界上最先进的开源关系型数据库”自居的项目，在正式发版的前夜，被迫紧急刹了车。
下面是我整理的整个时间线。
- 原定时间：PostgreSQL 每年秋季发布一个大版本，PG 18 于 2025 年 9 月 25 日发布，PG 19 原本预计在今年 9 月底至 10 月底之间与用户见面。
- 10 月初：发布团队宣布将 GA 定在 10 月 29 日。
- 10 月中旬：发布团队再度宣布，
GA 推迟到 11 月 19 日，并额外插入一个 RC2（11 月 12 日发布），让大量积压的修复先经历一轮社区验证。 - 与此同时，
8~10 项重要功能被从 PG 19 分支中撤回，其中相当一部分是在 Beta 周期相当靠后的阶段才被砍掉的。
要知道，正常一个大版本周期里，被撤回的重要功能一般是 1 项左右。一次砍掉接近 10 项，这个体量史上首次。
PostgreSQL 核心提交者、EDB 副总裁 Peter Eisentraut 在 10 月 9 日专门写了篇博客复盘此事，博客标题带着几分自嘲，The reverts will continue until morale improves（撤回的势头会一直持续，直到士气好转）。而他给出的核心解释中，有一个关键词反复出现，LLM 辅助代码审查。
于是问题来了，一个由全球最顶尖的 C 语言开发者守护了三十年的代码库，怎么会被 AI “找茬”找到了不得不延期发布的程度？
AI 写了烂代码？
事件发酵后，很多人第一反应是不是开发者用 AI 批量生成了大量质量堪忧的代码，结果在 Beta 阶段集中爆雷？
Peter Eisentraut 明确否定了这个猜测。他在博客中写道，这些被撤回的功能绝大多数是在 LLM 辅助编程和代码审查成熟之前就已经写好的，根本不存在“AI 写了烂代码”这回事。
真正发生的事情是这些功能当初开发和提交时，行业还没有如今这样的 LLM 审查能力；等到 PostgreSQL 19 准备发布时，新的工具已经可以发现过去五年都难以发现的问题。
Peter 把发现的问题大致分成两类。
- 架构层面的严重缺陷：一些被撤回的功能存在底层设计问题，在 Beta 阶段短时间内根本修不完；
- 长长的边缘问题尾巴：大量单看并不严重、只在特定怪异条件下触发的小问题。
第二类是重点。按照过去的节奏，这些问题往往不会在发布前暴露。数据库先发版，之后几年里随着真实用户撞上各种罕见组合，再靠小版本补丁一点点修掉，“5 年内自然消化”是常态。
但现在，AI 把这个消化过程压缩到了几周。Peter 举例说，开发者突然面对大约 40 份缺陷报告，即便每个问题平均只需要改 3 行代码，处理每一个问题仍然有人力和流程上的固定成本。确认是真 Bug、写修复、跑测试、找人审查合并。代码可能只改几分钟，但几十个问题叠加起来，人类的时间很快就被耗光了。
他把这个现象概括为一句话，有效质量门槛被抬高了（the effective quality bar has been raised）。
代码写完并被合并时，它符合当时的发布标准；等发布时，新标准已经把它判定为“不够好了”。一个很反直觉的结论由此诞生，AI 提高了软件质量，却可能在短期内降低软件的发布速度。
Vulnpocalypse 漏洞
不过，把延期全部归因于 AI 审查也不公平。Peter 在博客里还点出了另一件事，今年 PostgreSQL 社区经历了一轮密集的安全问题处理，被戏称为 Vulnpocalypse（漏洞末日）。
从社区披露的信息看，今年的安全问题数量远超往年，大量安全修复涌入各维护分支。这直接导致一个时间线上的错位。
- 4 月：PG 19 功能冻结，同时 Vulnpocalypse 开始；
- 4 月到 8 月：大量资深开发者被迫投入安全修复，Beta 阶段本该进行的额外评审和测试被大幅削减；
- 8 月之后：安全压力稍减，审查和测试重新铺开，于是一批问题在 Beta 后期才被集中发现。
换句话说，AI 负责把问题“加速挖出来”，而安全潮负责把“处理问题的带宽”抽空，两者叠加，最终造就了这次罕见的发布事故。
Peter 坦言，如果再给社区两个月，其中不少问题大概率是能修完的；但社区最终选择了“守住发布节奏、砍掉不稳的功能”，而不是“无限期延期修完所有长尾问题”。理由也很朴素，你永远不知道长尾到底有多长。
SQL/PGQ 属性图查询延期
在所有被撤回的功能中，最有代表性的当属 SQL/PGQ（属性图查询），这是 SQL:2023 标准引入的图查询能力，允许在关系型数据库上用标准 SQL 语法查询节点和边组成的“图”。
它的下马过程，堪称“AI 参与开源项目风险筛查”的完整样本。
- 第一步，AI 做风险评估。今年 8 月，社区成员 Robert Haas 让 Claude 根据 feature freeze 之后修复的 Bug 数量和类型，对 PG 19 的补丁进行“恐怖程度”排名。结果 SQL/PGQ 被列为高风险功能之一，当时它已经经历了 17 次 post-freeze 修复，问题包括错误的排序规则、未解析的字面量、损坏的 LATERAL 引用、deparse 和 pg_dump 的权限缺陷等。
- 第二步，人类资深开发者压上判断。核心开发者 Tom Lane 随后在邮件列表里放话，如果 SQL/PGQ 按当时的状态进入 PG 19，他愿意“赌一顿晚饭”，断言发布后一定会发现只能等到 PG 20 才能彻底解决的问题，因为需要修改解析树或系统目录的问题还在讨论中，这种级别的修复不可能塞进已发布版本。
- 第三步，AI 深度审查补刀。另一位核心开发者随后对 PGQ 启动了一次针对性 AI 审查，让人惊掉下巴的是，AI 又翻出了一批此前从未被报告过的真实问题，且经人工确认“全部成立”，包括并不限于下面这些问题。
- 一旦角色持有属性图上的任何权限，
DROP OWNED BY就会失败，进而导致DROP ROLE卡死在残留的依赖行上； - 当边的键从外键推断而来时，
pg_dump 会静默丢失整个图，对数据库工具来说，静默丢数据几乎是最严重的罪名； - 非唯一键会产生错误结果，而且不止一种触发路径；
- 查询里用上
GRAPH_TABLE后，不带限定的FOR UPDATE会被静默接受，并且什么都不锁，回归测试甚至把这条行为记录为 “– ignored”，而这不仅是“功能缺失”。元素表只拿 AccessShareLock、读侧甚至不需要 UPDATE 权限，两会话测试能直接证明所谓的“锁”形同虚设，存在实打实的安全边界问题； - 权限模型存在“三处互相矛盾的检查面”：建图要求“拥有”（ownership）而非 SELECT 权限，与文档中“行为类似 security invoker 视图”的描述直接冲突；查询时图 ACL 按视图属主检查、元素表却按调用者检查，成了规则文档中未记录的第二个例外。
邮件里的部分原话如下所示。
I started an AI review. Which found some not good stuff. I checked manually that all of these actually are issues.
我做了一次 AI 审查，发现了一些不妙的东西。我人工确认过，这些全都是真实问题。
最终，SQL/PGQ 被撤回，预计修正后重新进入 PostgreSQL 20。
顺便一提，社区还有人给这场风波排了一份“责任名单”，发起“恐怖补丁大赛”的 Robert Haas、呼吁撤回 8 项功能的 Noah Misch、以及只呼吁撤回 2 项但其中就包括 PGQ 的 Andres Freund。当然，写这份名单的人随即补充说这是反讽，这些人恰恰是保证 PG 19 稳定性的功臣。
数据库的组合地狱
为什么偏偏是数据库、偏偏是 PostgreSQL，最先撞上这个问题？
Peter 在博客里给了一个非常精彩的解释。PostgreSQL 的魅力之一在于“一切皆可与一切组合”（everything works with everything）。一个 SQL 层面的新功能，不仅要能在最简单的情况下跑通，还可能会被放进 domain、复合类型、分区表、视图、安全定义函数、触发器等任意环境里，并且这些能力还能继续互相嵌套。
他举了一个抽象的例子。某个 SQL 新特性，需要面对这样一种组合，domain 套在复合类型上，复合类型里的字段本身又是 domain；domain 带有非空约束；某一列被删除后重新添加；该表是一个被 detach 后又以不同列顺序 attach 回来的分区；而这一切又出现在一个视图里，视图从触发器中的 security-definer 函数里被调用。
理论上，PostgreSQL 的用户期待这些东西全部正常工作，这是这个数据库的立身之本，Peter 明确表示不想放弃这一点。但现实是人类甚至无法枚举出所有组合，更不可能逐个手工测试。
而这恰好是 LLM 辅助模糊测试（fuzzing）的主场，模型可以不断生成边缘组合、构造测试输入、观察异常，再沿着异常路径持续扩展。Peter 因此判断，这类 AI 辅助模糊测试未来必须直接进入功能开发流程，而不是等到 Beta 后期才集中使用。他还抛出了一个更长期的设想，社区已经在讨论，是否可以给功能加上某种“实验性（experimental）状态”先提交进主干、再逐步成熟的机制，这次被撤回的功能中，有好几个本来会因此受益。
PG 19 重量级功能
经过这一轮 AI “找茬”爆出的各种 bug，PG 19 绝不是变成了“小版本”。Peter 反复强调，经此一役，PG 19 反而会是一个异常稳健的版本。仍然保留的重量级功能包括：
- REPACK CONCURRENTLY：无需长时间锁表即可完成 REPACK（类似无锁版 VACUUM FULL），对运维是重大利好；
- 序列的逻辑复制：这其实是一个“撤回功能王者归来”的例子，它本身当年就曾被撤回过，如今修好回来了；
- pg_plan_advice 查询规划器提示：通过标准接口给规划器提供提示的能力，是社区多年呼声很高的功能。
至于 PostgreSQL 20，几个月前 Peter 还开玩笑说“PG 20 可能没什么新功能，只能修 Bug”；现在剧情彻底反转了，PG 19 撤下的一批功能，已经为 PG 20 攒下了一批接近完成、只需“再完成剩下 80%”的候选特性。
结语
Claude Code、Codex 这类工具成熟之后，“AI 写代码”早已不是问题；PostgreSQL 19 事件则展示了下半场，当 AI 同样能大规模审查、测试和攻击代码之后，“发现问题”也不再是问题。
AI 写代码可能很糟糕，需要人工审查；人工写代码也可能很糟糕，需要 AI 找茬，两者结合质量更有保证。LLM 写代码可能烂尾，但让它读代码找问题，成本极低，用好 AI 找 bug 也很不错。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 突发，PostgreSQL 19 延期，约 10 项核心功能被紧急撤回