PostgreSQL 小版本升级翻车：18.2/17.8等版本现BUG，建议暂缓部署

一周前，PostgreSQL 社区发布了二月份的例行小版本更新。不过，这里必须给各位提个醒：近期最好不要进行 PostgreSQL 的新增部署或版本升级。原因很简单，这个例行小版本不幸引入了两个 BUG。根据官方计划，它们将在 2026 年 2 月 26 日通过一个号外小版本（out-of-cycle release）来修复。

问题表现

BUG 1：substring() 对非 ASCII Toast 文本报错

这次引入的回归问题可能对业务产生直接影响。第一个主要问题是 substring() 函数在处理来自 TOAST 压缩列的非 ASCII 文本时会抛出错误。

相关讨论详见：https://www.postgresql.org/message-id/19406-9867fddddd724fca@postgresql.org

如果你的数据库中存储了超过 2 KB 的非 ASCII 文本（例如中文、日文等），并在该列上使用 substring() 函数，就有可能触发此问题。substring() 作为一个常用的字符串函数，实际业务中的命中概率并不低。

这个回归与修复 CVE-2026-2006 安全漏洞有关。该修复加强了对多字节字符的边界检查，将旧版本中“遇到不完整多字节字符时停止计数”的行为，改为了直接抛出错误。

问题的根源在于 text_substring() 函数中处理 TOAST 值解压切片的逻辑。当函数处理的文本值直接来自数据库列时，它会按照 请求的字符数 × 编码最大字节数 来预估解压长度，然后进行切片。这个切片操作有可能在多字节字符的中间位置截断数据。旧版本逻辑能够容忍这种情况，但新引入的安全检查会将其判定为无效字节序列，从而报告“invalid byte sequence for encoding”错误。

这也解释了为什么 SELECT substring('中文测试', 1, 2) 这样的查询可以正常工作，而 SELECT substring(col, 1, 2) FROM t 却可能报错。根据源码调用链推断，left()、right() 等字符串函数可能走相同的处理路径；但官方公告明确点名的是 substring() 函数。

BUG 2：新版本回放旧版本 WAL 时 FATAL 中断

第二个问题出现在跨小版本的 WAL 回放路径上，具体报错信息是：“could not access status of transaction”。

相关讨论详见：https://www.postgresql.org/message-id/349f9c82-3a8b-48ad-8cc4-fe81553793dd%40iki.fi

这个问题主要出现在“使用新的小版本二进制程序回放旧的小版本生成的 WAL 日志”这一场景中。除了主从流复制中备库追 WAL，还包括使用归档日志进行时间点恢复（PITR）等操作。不过，考虑到其触发条件相对特殊（需要特定的 WAL 记录组合），实际影响范围可能有限。

影响范围与应对建议

受影响的 PostgreSQL 版本包括：18.2, 17.8, 16.12, 15.16, 14.21。

如果你的应用使用了 substring() 等字符串函数处理非 ASCII 文本，并且已经升级到了上述小版本，那么你已经受到了第一个 BUG 的影响。对于第二个 BUG，可以检查一下流复制备库或恢复操作的日志中，是否有出现“could not access status of transaction”报错。

给所有用户的建议：

1. 暂缓部署：如果你计划近期部署新的 PostgreSQL 实例或进行版本升级，强烈建议等到 2026 年 2 月 26 日的号外版本发布之后。
2. 已升级用户：如果你已经安装了上述受影响的版本，请密切关注 2026 年 2 月 26 日的发布，并在发布后尽快更新到修复版本（18.3, 17.9, 16.13, 15.17, 14.22）。
3. 紧急修复：鉴于 PG 18.2 本身也修复了一系列 CVE 与 BUG，我们认为最佳的部署策略还是等待一周后的 18.3。如果业务上非常紧急，可以参考官方 Wiki 手工应用补丁并重新编译安装。

Pigsty 用户请注意：
如果你在最近一周内使用了 Pigsty 的“在线安装”模式，或者使用了 v4.1 的“离线安装包”进行了新的 PostgreSQL 部署，那么你很可能已经安装了受影响的 PG 版本。Pigsty v4.2.0 将与 PG 18.3 同期发布，届时会提供最新的离线安装包，以及将现有 PG 小版本升级到最新版的迁移指南。

如果你确实需要在这两周内部署新实例，可以考虑使用 Pigsty v4.0 的离线安装包，它包含的是 18.1 系列小版本，可以在后续通过小版本升级的方式跟进。

回顾与思考：为何小版本升级频频“翻车”？

最近几年，PostgreSQL 一共有过四次计划外的小版本发布（out-of-cycle release），最近三次都发生在年度例行更新之后：

• 2026-02-26 (计划中): 修复 substring() 回归及 multixact WAL 回放问题。
• 2025-02-20: 修复 CVE-2025-1094 安全补丁引入的 libpq 客户端库回归。
• 2024-11-21: 修复 CVE-2024-10978 安全补丁导致的 ALTER USER ... SET ROLE 失效问题，以及 ResultRelInfo ABI 变化引发的扩展兼容性问题。

连续三年的模式非常清晰：例行更新之后紧跟紧急修复，且问题多由安全补丁引入的回归导致。这背后反映出几个结构性矛盾：

1. 安全修复的时限与质量矛盾：CVE 修复有保密期，补丁在公开前只能在极小范围内进行审查和测试。与可以公开讨论数周甚至数月的普通 BUG 修复不同，安全补丁的开发与审查窗口极短，参与人员也少，很容易出现测试不充分的情况。
2. 测试体系相对滞后：PostgreSQL 历史悠久，但 make check 回归测试套件对多字节编码、跨版本流复制、扩展 ABI 兼容性等复杂场景的覆盖有限。2024 年因结构体大小变化导致 TimescaleDB 等扩展崩溃的事件，就说明对 ABI 稳定性的自动化检查尚有不足。
3. 用户期望与质量标准提高：随着 PostgreSQL 用户基数增长和在关键业务中的重要性提升，社区对质量的容忍度降低了。发现问题后，更倾向于快速发布修复，而非等到下个季度。这本身是一种对用户负责的态度。

连续“翻车”揭示了一个核心矛盾：安全修复所需的封闭、快速流程，与日益复杂的代码库及全面的测试需求之间难以调和。好在 PostgreSQL 拥有庞大的用户基数，问题能很快在生产环境的“众测”中被发现。

另一个值得思考的启示是：我们通常认为升级小版本是足够安全的，但这几次事件提醒我们，追新始终伴随风险。对于普通用户而言，在非紧急情况下，或许滞后一两个小版本使用，是更稳妥的策略。

数据库世界风云变幻，保持关注与谨慎总是没错的。想了解更多关于数据库的深度讨论和技术实践，欢迎来云栈社区逛逛。