PostgreSQL 核心提交者 Robert Haas 10 月 30 日写了一篇博客，解释今年的大版本为什么晚了。过去十年，PostgreSQL 主版本都在 9 月中旬到 10 月中旬之间发布，而 PostgreSQL 19 大概率要等到 11 月，项目方也可能再往后推。他给出的原因只有一句话：
“The short answer is that LLMs happened.”（简单说，就是 LLM 来了。）
Haas 现在是 Databricks 的高级资深软件工程师。这篇文章是他的个人判断，他也没有给出新的发布日期。
三个大功能在最后一个月被撤回
每年的功能冻结都在 4 月 8 日，冻结之后撤回功能并不稀奇。今年不一样的地方在于时间点和分量：8 月 27 日到 9 月 15 日之间，三项大功能被陆续回退。
UPDATE/DELETE FOR PORTION OF- SQL 属性图查询（SQL/PGQ）
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
按 Haas 的说法，往年也会撤回，但很少在这么晚的时候一次撤掉好几个大功能。
提交数涨了六成，提交者没有变粗心
他把统计窗口固定在每年 4 月 8 日到 9 月 25 日，比较两年的修复量。去年进入 REL_18_STABLE 的提交是 724 个，今年进入 REL_19_STABLE 的是 1169 个，增长超过 60%。再看上一个稳定分支，去年 REL_17_STABLE 是 248 个，今年 REL_18_STABLE 是 433 个，增长超过 74%。
这些提交多出来，Haas 不认为是大家写代码变差了。他判断提交者的谨慎程度跟往年差不多，变化出在发现环节：很多人开始用 LLM 给 PostgreSQL 找 bug，然后直接上报。
“What’s different now is that it’s become vastly easier to find those bugs.”（现在的不同在于，找到这些 bug 容易太多了。）
这层归因有一个缺口：提交记录不会标注 bug 是谁、用什么工具发现的，文章也没有给出 LLM 报告在其中的占比。上面的增幅是实测，“主要因为 LLM”是一位老提交者的观察。
卡住的是人工审查
延期的机制分两层。第一层，bug 多了，修复自然更花时间。LLM 能起草补丁，但补丁未必正确，也未必符合项目规范，最后还得由提交者逐个审完再合入。第二层更隐蔽：本来该用来审查新版本内容的时间，被安全问题和旧分支缺陷占走了，于是判断哪些功能该撤回这件事也被拖晚。
这跟前几天 Epoch AI 那个 Firefox 实验可以放在一起看。Epoch 测的是攻击一侧，用 GLM 5.3 抢在补丁公开后的窗口期写利用，每个版本约 1000 美元算力。Haas 讲的是维护一侧：同样的能力落到几十年老项目上，报告量先涨，能审代码的人数不会跟着涨。两边的共同变量是发现漏洞的成本，它掉得比修复成本快。
这对国内团队也不算远。不少云数据库产品基于 PostgreSQL 做二次开发，上游回合量涨六成到七成，下游跟进补丁的工作量也可能相应变大。具体影响有多大，目前没有厂商给过数字。
四十年的存量才是远期压力
Haas 对这次延期本身并不紧张，他说放到长周期里这不算久，而且它来自项目对质量的坚持。他也强调，AI 找到这些问题并没有改变他对代码库质量的评价。
让他没底的是后面。项目积累了约四十年人类没发现的 bug，LLM 能挖出不少，他的原话是 “how are we ever going to catch up”。今后每一个新功能都会被 AI 审一遍，这既是压力，也可能让代码更扎实。他没有给出解决方案，只说自己和很多人正在想办法。
PostgreSQL 19 最终落在哪一天，要看发布团队接下来的公告。
参考来源：Robert Haas 个人博客；CocoLoop；Epoch AI 公开实验报告；分支提交统计以 Haas 文中给出的口径为准，未单独复算。