PostgreSQL 19 没有按十年惯例在九十月发布，正式版推到 11 月 19 日，RC1 已在 10 月 15 日出，RC2 定在 11 月 12 日。官方给的表面理由是可靠性优先，但核心提交者 Robert Haas 的博客把真实原因说得很直白。
数据摆在这里
同一个窗口（4 月 8 日特性冻结到 9 月 25 日）：2025 年稳定分支落了 724 个提交，2026 年同期是 1169 个，涨了 60% 以上。而进主干的提交反而略降。也就是说，新增代码没有变多，回补修复爆炸了。
更狠的是跨分支回补：需要同时打到上一个稳定分支的修复，从 248 涨到 433，一年涨了 74%。
原因
一大批人拿 LLM 去扫 PostgreSQL 的代码库，扫出来的问题往邮件列表一报。模型也能起草补丁，但草稿质量参差，每一个都必须人来评审和提交。用 Haas 的话说，人并没有在两年里变聪明。
代价是什么
本该用来审查 v19 新特性的时间，被挪去处理历史分支的安全与缺陷，导致新代码的问题暴露得晚。8 月底到 9 月中旬，三个大特性被撤：SQL/PGQ 属性图查询、UPDATE/DELETE FOR PORTION OF、ALTER TABLE 的 MERGE/SPLIT PARTITION。到 9 月中旬，beta 以来的回退已经数到 53 个。
最终交付了什么
并行 autovacuum、REPACK（含并发版）、pg_plan_advice 查询计划建议、ON CONFLICT DO SELECT 都还在。破坏性变更要注意：JIT 默认关闭、移除 RADIUS 认证、默认 TOAST 压缩改为 lz4。
这件事的普适意义
这是第一次有大型开源项目公开承认：AI 辅助审查把缺陷发现速度提到了人力修复能力之上。所有维护着十年以上代码库的团队都会撞上同一堵墙。解法不是关掉 AI，而是建立缺陷分级与自动化验证，让机器承担更多确认工作，人只处理真正需要判断的部分。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
