从 2016 年的 PostgreSQL 9.6 到去年的 PostgreSQL 18，这个全球最受信任的开源关系型数据库连续 10 个大版本从未爽约过“9 月中旬至 10 月中旬”的秋季发版窗口。但在今年，PostgreSQL 19 罕见地破例了——历经增发 Beta 4 与 RC 2 两次“加赛”，官方已将正式版（GA）计划日期推迟至 2026 年 11 月 19 日，并在测试后期集中砍掉了 8 到 10 项已经合入的重大新特性。
拖慢发版节奏的并不是外界第一反应猜测的“AI 写出了太多烂代码”，恰恰相反，是全网安全团队与内核维护者手里的 LLM 找 Bug 太快了。当受支持分支的年度真实安全漏洞（CVE）暴涨逾 5 倍、向已发布旧生产分支跨代回溯的补丁一年激增 74.6%，全球仅有的 31 名活跃提交者第一次正面撞上了人类审查与回归验证的吞吐极限。
一、十年发版铁律破功与两次罕见“加赛”
三次退守的秋季日历
如果你平时负责维护生产环境的 PostgreSQL 集群，大概率早就习惯了它像瑞士钟表一样的年度节奏。翻开官方版本生命周期记录，过去十年连续 10 个主版本的首发日期全部精准落在 35 天的窄窗口里，最早是 9 月 14 日（PG 16），最晚也没超过 10 月 18 日（PG 11）。哪怕去打开官方静态的开发路线图页面，主版本计划栏里直到 10 月下旬还留着没来得及改掉的“October 2026”。
裂痕其实在今年初夏就已经露头了。和去年的 PG 18 一样，PostgreSQL 19 在 4 月 8 日 12:00 UTC 准时完成了最后一次 CommitFest 特性冻结；但去年 5 月 8 日就端出来的首个测试版 Beta 1，今年一直憋到 6 月 4 日才发布，起步就晚了将近一个月。
进入 9 月后，发布协调人、核心团队成员 Jonathan S. Katz 在 pgsql-hackers 邮件列表里连发三封排期通知，清晰记录了社区试图守住十年惯例却最终退守的全过程：
- 9 月 3 日（增发 Beta 4）：宣布在 9 月 24 日增发非常规的第四个测试版 Beta 4（常规周期通常只需 3 个 Beta）。他在邮件里直言，此举是为了应对“近期涌入且耗费额外时间处理的大量问题报告”，并在脚注里直接贴出了单次修掉 28 个 CVE 的
18.6发行说明作为例证。当时团队的目标仍是力保 10 月底前发版。 - 9 月 28 日（试图卡点 10 月底）：Beta 4 发完四天后，团队给出了一份紧凑的冲刺排期——定于 10 月 15 日发 RC 1，不设 RC 2，力争在 10 月 29 日直接推出正式版，赶在 11 月例行小版本更新前留出两周缓冲。
- 10 月 10 日（增发 RC 2，正式推迟至 11 月）：距离 RC 1 只剩五天时，发布团队终于决定不再硬撑，宣布在 11 月 12 日增发 RC 2（与 Q4 季度例行小版本同日发布），先把各旧维护分支新攒下的一大批修复合入验证一周，再于 11 月 19 日发布 PostgreSQL 19 正式版。10 月 15 日的 RC 1 官方公告正式确认了这一日程，同时保留了“若发现阻塞问题仍可能继续延期或增发候选版本”的前提。
61.5% 与 74.6% 的两组 Git 提交账本
为什么旧分支的修复补丁会多到把新大版本硬生生挤出十月？
10 月 21 日，资深提交者 Robert Haas（现任职于 Databricks）在 Neon 博客发了一篇标题毫不客气的复盘长文——《Postgres 19 迟到了，这得怪 AI》（10 月 30 日同步至个人博客后引发全网热议）。他在文里拉出了 2025 年与 2026 年完全同口径时间窗口（每年 4 月 8 日特性冻结至 9 月 25 日）的官方 Git 仓库提交账本。
这两天不少二手资讯把“挖出陈年老 Bug”和“回溯补丁暴增 60%”混成了一谈，如果直接拆开 Haas 统计的原始分支数据，真实的数字其实更有冲击力：
| 统计维度（每年 4 月 8 日至 9 月 25 日） | 2025 年（PG 18 周期） | 2026 年（PG 19 周期） | 同比变化 | 实际工程含义 |
|---|---|---|---|---|
master 主干总提交数 |
1,037 次 | 1,443 次 | +39.15% | 仓库整体代码变更吞吐总量 |
仅入 master 的纯新开发提交 |
313 次 | 274 次 | -12.46% | 面向下一代大版本的新特性开发反而略降 |
| 合入当届在研稳定分支提交 | 724 次（REL_18_STABLE） |
1,169 次（REL_19_STABLE） |
+61.46% | 含 v19 新特性修补/回滚及主干同步回溯（即“逾 60%”口径） |
| 跨代回溯至已发布旧生产分支提交 | 248 次（入 REL_17_STABLE） |
433 次（入 REL_18_STABLE） |
+74.60% | 真正衡量影响既有线上版本的历史 Bug 修复（一年暴涨近四分之三） |
账面非常清楚：提交者们今年写新功能的代码量不仅没涨，反而还少了 12.5%；真正把仓库撑爆的，是从主干往在研分支回溯的 1,169 次提交（+61.46%），尤其是那些必须跨代往至少一个已发布历史生产版本打补丁的陈年缺陷修复，单年猛增了 74.60%。
并不是“Vibe Coding”惹的祸
看到“AI 导致数据库延期”和“大量特性被回滚”，很多人的第一反应是：是不是这帮开发者开始用 AI“凭感觉写代码（Vibe Coding）”，把一堆半成品塞进了内核？
另一位核心团队成员兼提交者、EDB 副总裁 Peter Eisentraut（他本人就是今年多项被回滚特性的作者或提交者）在 10 月 9 日发表的《回滚还将继续，直到士气改善》中直接否定了这个猜测。
他指出，今年受影响被回滚的绝大部分特性，早在 LLM 代码审查成熟之前就已经写完提交了；提交者合入代码时的审慎尺度与往年也没有区别。真正发生剧变的是另一头——“有效质量门槛是在特性编写并提交之后，被事后抬高了。”
在过去，一套复杂数据库特性的边缘组合缺陷，往往会在正式发版后的 5 年时间里随着不同用户的极端生产负载零星浮出水面，社区可以按部就班地一点点修补。但今年，全网研究者和开发者拿着前沿大模型对着源码做辅助审查与模糊测试，硬是把原本分散在五年周期里的长尾隐患，一次性折叠并引爆在了这一个夏天。
二、2026 漏洞风暴与潜伏 20 年的代码死角
不是垃圾报告轰炸，而是高危真洞洪峰
今年开源界苦“AI 垃圾报告（AI Slop）”久矣。1 月底，cURL 因为 HackerOne 上的 AI 虚假漏洞报告泛滥、有效率跌破 5%，直接关停了漏洞赏金计划；8 月下旬，QEMU 仓库更是遭单一账号在不到 10 分钟内倾泻了 132 条未经核实的 AI 生成 UBSan 报错，被红帽资深维护者公开定性为针对维护者心智带宽的“拒绝服务攻击（DoS）”。
因此在 Hacker News 的讨论区里，不少外部开发者一开始以为 PostgreSQL 也是被低质量的 AI 幻觉报告拖垮的。但翻开 PGDG 官方的安全漏洞总台账就会发现，PostgreSQL 遭遇的根本不是假报告骚扰，而是一场实打实的高信噪比“漏洞风暴（Vulnpocalypse）”。
尽管官方并未披露私密安全邮箱（security@postgresql.org）后台拦截了多少无效误报，但仅看经过安全团队严格复现、确认影响受支持分支（PG 14–18）并正式分配编号的真实 CVE 数量，曲线就已经彻底陡峭化了：
- 2023 年全年：7 个 CVE
- 2024 年全年：7 个 CVE
- 2025 年全年：7 个 CVE
- 2026 年前三次例行更新（截至 8 月）：44 个 CVE（外加逾 235 个普通 Bug，11 月 12 日待发的第四批尚未计入）
连续三年稳如直线的“每年 7 个”，在 2026 年前三个季度直接飙到了 44 个，同比暴涨 528.6%（往年全年均值的 6.29 倍）。拆开今年这三次季度更新，压迫感是一浪高过一浪的：2 月 12 日（18.2 批次）修了 5 个 CVE；5 月 14 日（18.4 批次）涨到 11 个；到了 8 月 13 日（18.6 批次），单次集中修复了创纪录的 28 个 CVE 和超过 110 个普通 Bug，其中约一半是 CVSS 8.8 级的堆缓冲区溢出、整数溢出、类型混淆或任意代码执行高危漏洞。
致谢栏里的 AI 安全战队与“撞洞”奇观
去读今年这三次安全公告和 18.6 官方发行说明的致谢栏，简直像在看全球前沿大模型与自动化漏洞引擎的实战榜单：
- Claude & Anthropic Research：5 月联合 Calif.io 报告了
hstore二进制输入栈溢出（CVE-2026-6479）；8 月联合安全研究员 Ben Morris 一次性署名 3 项高危漏洞，包括ltree堆缓冲区溢出（CVE-2026-16239）、EXTRACT()反解析超管 SQL 注入（CVE-2026-15741）与角色列表反解析注入（CVE-2026-15742）。 - OpenAI Codex Security：Amy Burnett 与 OpenAI 安全研究团队在
18.6中连续署名tsquery内存越界读与栈溢出（CVE-2026-14669）、btree_gist堆溢出（CVE-2026-16238）及统计信息计算任意内存读取（CVE-2026-14680）。 - 国内外专精 AI 审计引擎：自动化代码审计团队 Xint Code（累计署名 5 项 CVE）、网络安全初创公司 AISLE（年初曾用自主系统包揽 OpenSSL 单次发布的全部 12 个 CVE）、腾讯玄武实验室 XlabAI 团队联合 Atuin 自动化漏洞挖掘引擎（
CVE-2026-6475）、蚂蚁 AntAISecurityLab（联合复旦大学）以及 TrendAI ZDI 悉数在列。
当全世界的安全团队同时拿顶级模型去扫同一份拥有三四十年历史的 C 语言代码库时，诞生了两个极具时代标志性的现象。
第一个是二十年陈年死角被掀底。今年 2 月修复的高危漏洞 CVE-2026-2005（CVSS 8.8，允许密文提供方以数据库操作系统用户身份执行任意代码），由 Xint Code 团队借助 AI 审计发现。溯源 Git/CVS 历史可以发现，这段存在堆缓冲区溢出的代码早在 2005 年就随 pgcrypto 加密扩展合入了主库，在无数生产环境里潜伏了整整 20 多年，躲过了历代人工审计和传统 Fuzzing，直到今年才被大模型一眼看穿（同期 Xint Code 还在 MariaDB 里挖出了一个 2004 年引入、潜伏 22 年的栈溢出漏洞 CVE-2026-21576）。
第二个是十几家团队同时“撞洞”。在传统安全研究里，两个独立团队在同一个月撞上同一个深层漏洞就已经算是巧合；而在今年 5 月披露的 CVE-2026-6473（jsonb_populate_recordset 类型混淆导致任意代码执行）致谢名单里，官方罕见地列出了 10 组独立报告者；到了 8 月的 CVE-2026-14669，共同致谢名单更是刷新到了 11 组（OpenAI Codex Security 与蚂蚁 AntAISecurityLab 都在其中）。大模型不仅压低了挖洞门槛，还让不同团队在相近的推理路径上批量收敛到了同一批历史盲区。
三、31 名人类守门人的吞吐极限与三次回归惊魂
为什么不能直接让 AI 修 AI 挖出来的洞
既然大模型这么擅长找 Bug，为什么不直接让它生成修复补丁，甚至顺手把代码审查也干了？
答案藏在“生成容错率”和“内核背书责任”的巨大鸿沟里。根据 PGDG 官方的提交者名录，支撑起全球数百万企业核心数据库的 PostgreSQL 主代码库，目前拥有直接 Git 推送权限的活跃提交者（Committer）加起来只有 31 个人。
这 31 个人的分工高度重叠：其中 20 人同时兼任 PostgreSQL Security Team 成员，必须在不公开细节的前提下验证私密漏洞报告，并手动为 PG 14、15、16、17、18 五个受支持主版本编写和适配回溯补丁；而负责统筹今年大版本质量的发布管理团队（RMT）更是只有 3 个人（Nathan Bossart、Heikki Linnakangas、Melanie Plageman），前两位本人还得在一线亲自操刀编写今年多起高危 CVE 的修复代码。
Robert Haas 在复盘里说了一句很扎心的大实话：“LLM 可以起草修复补丁，但这些补丁并不总是正确的，也未必符合 PostgreSQL 的规范标准。它们仍然需要由人类来审查和提交，而这些人类在 2025 年到 2026 年之间并没有变得更聪明。”
PGX 首席顾问 Christophe Pettus 在《19th Nervous Breakdown》里记录过一个绝佳的真实案例：今年测试期间，资深贡献者 Thom Brown 用 Claude 成功定位到了新特性 REPACK 在逻辑解码场景下会导致整个集群崩溃的真实深层缺陷，Claude 也顺手给出了两处单行修复代码；结果原作者 Antonin Houska 审查时发现，AI 给的两处修改里有一处是错的，直接合入反而会破坏底层状态。
就算补丁逻辑真的只有寥寥几行，工程上的“刚性固定开销（fixed overhead）”也省不掉。正如 Peter Eisentraut 算的那笔账：当你面前突然摆着一份 40 条缺陷报告的清单，哪怕每条平均只需要改 3 行代码，从构造最小复现用例、在邮件列表里往返讨论边界影响、补齐回归测试，到手动跨越五六个历史分支解决冲突并观察跨平台构建农场（Buildfarm）结果，每一道工序都在实打实地消耗这 31 个人的心智带宽。
半年三次翻车与高频回溯引发的次生回归
更棘手的是，在高压之下往五个历史生产分支高频塞入几百个安全与缺陷补丁，已经在今年上半年对 PostgreSQL 引以为傲的小版本稳定性造成了肉眼可见的反噬：
- 2 月计划外紧急发版（
18.3）：2 月 12 日刚发完包含 5 个 CVE 修复的18.2系列，仅隔 4 天，官方就因安全补丁在多字节文本处理中引发了substring()严重回归，被迫宣布计划外更新，于 2 月 26 日紧急推出18.3 / 17.9 / 16.13 / 15.17 / 14.22救火。 - 5 月引入从库回放自死锁：5 月 14 日发布的
16.14 / 15.18 / 14.23（含 11 个 CVE 修复），在 PG 14–16 从库追随旧版本主库做 WAL 日志回放时意外引入了自死锁（self-deadlock）回归，一直拖到 8 月才彻底修复。 - 8 月罕见废弃并跳号
18.5：8 月中旬在打包封版（wrap）18.5之后、正式对外发布前的最后关头，团队又抓出了新的回归缺陷，被迫直接作废18.5这个版本号，在 8 月 13 日跳号发布了18.6。
把上半年这三次惊魂串起来看，就能彻底理解发布团队在 10 月 10 日的选择了。面对 11 月 12 日即将随 Q4 例行更新一起落地的又一大批回溯补丁，宁可打破连续十年的秋季发版纪录、多发一个 RC 2 让全网公开验证一周，也绝不能让未经充分烤机的大批底层改动直接混进 PostgreSQL 19 的首发正式版里。
四、Claude 驱动的“高危补丁审判”与断臂保稳
一封引爆回滚潮的邮件
4 月到 8 月的“漏洞风暴”不仅考验着旧分支，还抽走了资深提交者原本用来打磨 PG 19 新特性的黄金夏天。等大家在 8 月中旬好不容易从 28 个 CVE 的 18.6 发版里喘口气、转头审视即将进入候选期的 PG 19 时，留给他们的修补窗口已经所剩无几。
有趣的是，内核维护者们自己也拿起了大模型当手术刀。8 月 25 日，Robert Haas 在 pgsql-hackers 发起了一场名为 scary patch contest（高风险补丁评估）的讨论——他让 Anthropic Claude 系统审计了 4 月 8 日冻结之后各个新特性的缺陷修复次数与故障性质（还在邮件里调侃说删掉了几句 LLM 过于毒舌的评语），点名了 6 项最让人捏一把汗的补丁集：
REPACK / REPACK CONCURRENTLY：冻结后累计 28 次修复，包含数据丢失隐患；- 在线启停数据校验和：约 25 次实质性修复，多为状态机漏洞，且出现了“损坏检测功能误报数据损坏”的致命故障模式；
UPDATE / DELETE ... FOR PORTION OF时态修改：17 次修复，其中 3 项属于绕过行级安全（RLS）或权限检查的安全漏洞；SQL/PGQ属性图查询：17 次修复；- 外键快速路径与批量检查：约 16 次修复，含越界写与 5 类错误约束执行；
postgres_fdw统计信息导入：冻结日当天压线合入，区区单文件 contrib 代码后续竟修了 7 次。
与此同时，提交者 Noah Misch 也在用 Claude Opus 5 扫描主干代码；老将 Tom Lane 甚至在 8 月 28 日的一处查询规划器补丁提交说明里公开注明“初稿由 Claude Opus 4.8 生成”（不过他依然保持着极度务实的克制，果断拒掉了外部用 AI 批量生成、徒增永久测试运行时开销却缺乏性价比的测试用例集）。
砍掉 8–10 项重大特性，留住了什么
在往年的常规周期里，PostgreSQL 进入 Beta 阶段后通常只会回滚 1 项左右的新特性。而在今年 8 月底到 9 月中旬的三周内，为了保住发版底线，核心团队掀起了一场史无前例的晚近大回滚，按统计粒度不同共撤下了 8 至 10 项重大特性（据 Snowflake 工程团队统计，Beta 启动至 9 月中旬分支上累计出现了 53 次 revert 提交）：
SQL/PGQ属性图查询（9 月 7 日回滚）：本周期体量最大的明星特性，单次撤销提交直接删掉了 124 个文件、约 1.6 万行代码。核心硬伤在于缺少依赖对象删除锁，且彻底修复必须改动系统表目录（catversion）。Tom Lane 在讨论中直接放话“愿赌一顿晚餐，要是强行在 v19 发出来，必将留下只能等 v20 才能修的漏洞”。- 在线启停数据校验和（9 月 16 日回滚）：经 Claude 辅助审查发现，集群历史崩溃遗留的孤儿关系文件会导致
pg_basebackup备份校验失败，短期内没有稳妥解法，最终连带撤销了 30 个关联提交。 UPDATE / DELETE ... FOR PORTION OF（9 月 15 日回滚）：因READ COMMITTED隔离级别下存在并发丢失更新等执行器缺陷及 14 项待办问题，撤销 23 个提交（PG 18 已有的WITHOUT OVERLAPS约束不受影响）。- 其余被撤回或局部裁剪的特性：包括
ALTER TABLE ... MERGE / SPLIT PARTITIONS分区合并与拆分、pg_get_role_ddl()等集群级 DDL 生成函数（撤销 12 个后续提交）、与非默认相等语义冲突的GROUP BY ALL、pg_dumpall非纯文本导出、排序规则专属大小写折叠以及CREATE SCHEMA子命令扩展。顺带澄清一个社区常见误传：外键检查提速并没有被全盘砍掉——提交者 Amit Langote 在 9 月 10 日仅移除了容易与子事务冲突的“批量缓冲层（batching layer）”，而单行快速路径（per-row fast path）已顺利保留在 RC 1 中。
客观地说，这波大回滚也不能把责任 100% 推给外部的 LLM。Christophe Pettus 和 Layerbase 在核查 Git 时间戳后指出了硬币的另一面：在今年 3 月 10 日到 4 月 8 日“冻结悬崖（freeze cliff）”前的最后五周里，社区密集突击合入了 8 项深度耦合底层机制的大特性，REPACK (CONCURRENTLY) 甚至是在冻结前 40 小时带着 3 条已知设计空洞压线进场的。换句话说，冻结前的突击冲刺埋下了高复杂度的架构存量，而 LLM 漏洞风暴既在外部抽干了初夏的审查人力，又在内部加速揭穿了这些设计隐患，两股力量撞在一起，彻底击穿了按旧时代速率校准的夏季测试日历。
好消息是，经过这轮近乎残酷的“断臂保稳”，留在 PostgreSQL 19 RC 1 官方发行说明里的幸存特性含金量依然极高：
- 内核原生
REPACK与非阻塞REPACK (CONCURRENTLY)：通过主动收缩边界（限制全集群同一时刻单进程运行、仅限 heap 表、禁止事务块内带ANALYZE执行）挺过了审查，终于让 DBA 们看到了告别第三方扩展pg_repack的曙光； - 官方查询计划干预扩展
pg_plan_advice与pg_stash_advice：无需改写 SQL 即可精细控制连接顺序、扫描方式与并行策略； - 复制与高可用痛点补齐：支持序列值逻辑复制（Logical replication of sequences）、在
wal_level = replica下免重启直接开启逻辑复制，以及从库保障读写一致性的原生WAIT命令； - 运维与性能升级：并行自动清理（Parallel autovacuum）配合全新的优先级评分调度、单行快速外键检查、
INSERT ... ON CONFLICT DO SELECT、COPY TO (FORMAT json)，以及两项顺应生产实践的默认参数调整——默认关闭jit（改为off），并在编译支持时将default_toast_compression默认切换为lz4。
五、当 AI 能无限挖出下一个 Bug，什么才算“可以发版”
PostgreSQL 19 的这次推迟，大概率只是所有大型基础软件迈入 AI 审计时代的第一声惊雷。
为了避免明年重蹈覆辙，PostgreSQL 社区内部已经摆出了几套非常务实的流程改革提案：RMT 成员 Nathan Bossart 提议从 2027 年起试行将例行小版本更新从每年 4 次加密到每年 6 至 8 次（每 6–8 周一次），用高频小步快跑分摊单次攒下几十个 CVE 的回归风险；Peter Eisentraut 则呼吁把 LLM 辅助模糊测试前置到特性合入之前，因为 PostgreSQL 崇尚“万物皆可正交组合”（比如域嵌套复合类型、分区表异序拆装叠加上安全定义者触发器），靠人脑根本穷举不完组合爆炸，同时社区也在探讨引入主干“实验性特性（Experimental status）”分级机制，不必再逼着复杂特性在 4 月 8 日冻结悬崖前“要么一步承诺五年兼容、要么整年打回原形”。
横向看去，用工程化的防守侧 AI 来缓解人类维护者瓶颈也已经有了正面的先行样本。据 Phoronix 10 月初报道，Google 工程师为 Linux 内核社区构建的 Sashiko AI 代码审查系统已累计审查逾 19.1 万个内核补丁，并在 463 个 Linux 内核 CVE 的关联修复中被引用，帮部分子系统维护者省下了 60% 到 70% 的补丁初审时间。
但比工具和排期更难回答的，其实是 Robert Haas 在文章结尾留下的那个追问：“既然我们积攒了四十年来人类未能发现、但 LLM 却完全有能力挖出的 Bug，我们究竟该如何追赶？PostgreSQL 又该如何继续创新？眼下，我还没有答案。”
过去几十年里，基础软件之所以能按时发版，很大程度上依赖一种天然的速率平衡——只要当前没有已知的阻塞级缺陷，版本就是“足够好”的，剩下的长尾边缘问题留给时间慢慢暴露。可一旦机器拥有了近乎无限的算力去穷举四十年存量代码里的每一个极端分支，缺陷的发现速率就彻底脱离了人类的修复带宽。在 Hacker News 和国内技术社区的讨论里，已经有不少一线架构师开始担忧**“发布瘫痪（Release Paralysis）”**——当 AI 每天都能在老系统里再揪出十个十年没触发过的真实边缘 Bug 时，谁来拍板说“修到这里就可以停下发版了”？
这道题短期内恐怕没有标准答案。但至少在 2026 年的这个秋天，那 31 个“没有在一年之间变得更聪明”的人类数据库守门人，还是给出了最朴素也最让人安心的选择：不凑合带病上线的新特性，不迷信维持了十年的日历仪式感，哪怕跳票加赛，先把交到用户手里的数据底线守住。
参考与信源
- PostgreSQL Global Development Group: PostgreSQL 19 RC 1 Released!（确认 11 月 12 日 RC 2 与 11 月 19 日计划 GA，2026-10-15）
- Jonathan S. Katz (
pgsql-hackers): Updated PostgreSQL RC / GA dates（三次排期调整邮件归档，2026-10-10） - Robert Haas (Neon Blog): Postgres 19 is late, and it's AI's fault — LLMs are finding bugs faster than committers can fix them（Git 分支提交量 >60% / >74% 统计原文，2026-10-21）
- Peter Eisentraut: The reverts will continue until morale improves（关于 8–10 项特性回滚与“有效质量门槛事后抬升”反思原文，2026-10-09）
- Robert Haas (
pgsql-hackers): scary patch contest（Claude 辅助审计冻结后六大高危补丁集原始邮件，2026-08-25） - PostgreSQL Global Development Group: PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!（单次修复 28 个 CVE 与跳过 18.5 说明，2026-08-13）
- PostgreSQL Documentation: Appendix E.1. Release 18.6 & Security Information（官方安全漏洞总台账与 AI 安全团队致谢名单）
- PostgreSQL Security Advisory: CVE-2026-2005 — pgcrypto heap buffer overflow & CSO Online 深度报道（潜伏逾 20 年的 2005 年代码漏洞核实）
- PostgreSQL Global Development Group: PostgreSQL 19 Beta 4 Released! & Release 19 Documentation（回滚清单与 RC 1 保留特性官方说明）
- Christophe Pettus (The Build): 19th Nervous Breakdown（特性冻结悬崖复盘与 2027 年高频小版本提议记录，2026-09-15）
- Layerbase: When Will Postgres 19 Be Released?（上游回滚提交哈希与排期时间线核验，2026-10-15）
- LWN.net: PostgreSQL 19's "scary patch contest" & Haas: Postgres 19 is late, and it's AI's fault（2026-09-10 / 2026-10-30）
- Phoronix: AI Code Review System Has Reviewed 191k+ Linux Patches, Cited On 463 Kernel CVEs & AI-Generated Bug Reports "DoS Attack"（2026-08-25 / 2026-10-08）
