一周前 PostgreSQL 社區發布了二月度例行小版本更新，。 不過老馮必須提醒各位，最好不要在最近兩周進行 PostgreSQL 新增部署與更新，因為這個例行小版本引入了兩個 BUG。 這兩個 BUG 將在 2026-02-26 的 號外小版本（out-of-cycle release）中修復。

表現 BUG 1：substring() 對非 ASCII Toast 文本報錯

這次引入的回歸問題可能對業務產生影響。第一個主要問題是 substring() 函數從 Toast 壓縮列中取出非 ASCII 文本時會報錯。

https://www.postgresql.org/message-id/19406-9867fddddd724fca@postgresql.org[1]

如果你存儲了超過 2 KB 的非 ASCII 文本，并在列值上使用 substring()，就可能觸發這個問題。substring() 是常用字符串函數，實際命中概率并不低。

這個回歸與 CVE-2026-2006 的安全修復有關，CVE-2026-2006 的修復加強了多字節邊界檢查，把“遇到不完整多字節字符時停止計數”的舊行為，改為直接拋錯。

問題出在 text_substring() 的 TOAST detoast 切片邏輯。當值來自數據庫列時，函數會按 請求字符數 × 編碼最大字節數 預估解壓長度，再取切片。 該切片可能在多字節字符中間截斷，舊邏輯能容忍，新邏輯會報“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[2]

這個問題出現在“新小版本二進制回放舊小版本 WAL”場景中。除了主備流復制追 WAL，還包括使用歸檔做恢復（PITR）等回放路徑。 但考慮到觸發條件比較特殊，實際影響范圍可能相對有限。

影響

受影響版本：18.2、17.8、16.12、15.16、14.21。

如果您的應用使用了 substring() 等字符串函數處理非 ASCII 文本，且已升級到這些小版本，那您已經受到第一個 BUG 的影響。 第二個 BUG 觸發有一個前提，即“用新版本二進制回放舊版本 WAL”。建議檢查流復制備庫的日志中有無“could not access status of transaction” 報錯。

如果您安裝了 PostgreSQL 18.2/17.8/16.12/15.16/14.21，建議您密切關注 2026-02-26 的號外小版本發布，并在發布后盡快更新到 18.3/17.9/16.13/15.17/14.22。 鑒于 PG 18.2 修復了一系列 CVE 與 BUG，我們認為最佳的部署策略還是等待一周后的 18.3 發布再進行部署。如果您著急需要進行提前修復，可以參考官方 Wiki 手工應用補丁重新編譯構建與安裝。

對于 Pigsty 用戶來說，如果您在最近一周內使用“在線安裝”模式，或使用 v4.1 的“離線安裝包”進行了新的 PG 部署，那么您很可能已經安裝了受影響的 PG 版本。 Pigsty v4.2.0 將與 PG 18.3 同期發布，提供最新的離線安裝包，以及對現有 PG 小版本升級到最新小版本的遷移手冊。

如果您確實非常著急要在這兩周內部署上新，那么可以使用 Pigsty v4.0 的離線安裝包，安裝 18.1 系列小版本，并在后續進行小版本升級。

老馮評論

最近幾年，PostgreSQL 一共有過四次 out-of-cycle 計劃外小版本發布：

① 2026-02-26（計劃中）

?版本：18.3, 17.9, 16.13, 15.17, 14.22?原因 A（安全修復相關）：CVE-2026-2006 修復引入 substring() 回歸?原因 B（非安全變更）：multixact WAL 回放路徑回歸，備庫/恢復可能中斷

② 2025-02-20

?版本：17.4, 16.8, 15.12, 14.17, 13.20?原因：2025-02-13 發布的 CVE-2025-1094（libpq 客戶端庫漏洞）修復引入回歸，涉及非空終止字符串處理問題。?

③ 2024-11-21

?版本：17.2, 16.6, 15.10, 14.15, 13.18, 12.22（PG 12 已 EOL，仍破例發布）?原因 A（安全修復相關）：CVE-2024-10978 修復導致 ALTER USER ... SET ROLE 失效?原因 B（獨立問題）：ResultRelInfo ABI 變化導致部分擴展兼容性問題?

④ 2022-06-16

?版本：僅 14.4（只針對 PG 14）?原因：PostgreSQL 14.0 以來，CREATE INDEX CONCURRENTLY 和 REINDEX CONCURRENTLY 存在 靜默索引數據損壞 問題。

最近三次的號外小版本模式非常清晰：2024、2025、2026 連續三年的例行更新之后都緊跟了一次緊急修復，而且主要是安全補丁引入的回歸。我覺得背后有幾個結構性原因：

第一，安全修復的時間壓力與質量之間的矛盾。CVE 修復有保密期（embargo），補丁在公開前只能在極小范圍內審查和測試。 不像普通 bug 修復可以在 pgsql-hackers 上公開討論幾周甚至幾個月，安全補丁的開發和審查窗口非常短，參與的人也少，很容易測試不充分。 這三次：CVE-2024-10978 改壞了 SET ROLE、CVE-2025-1094 改壞了 libpq 字符串處理、CVE-2026-2006 改壞了 substring()都是修漏洞時引入了功能回歸。

第二，PG 的回歸測試體系相對于代碼復雜度來說是滯后。 PostgreSQL 的 make check 回歸測試套件歷史悠久但覆蓋面有限，特別是對多字節編碼、跨小版本流復制場景、擴展 ABI 兼容性這些維度的覆蓋不夠。 2024 年那次 ResultRelInfo 結構體大小變化導致 TimescaleDB 等擴展崩潰，說明 ABI 穩定性都沒有充分自動化檢查。 社區一直在討論引入更完善的 CI/CD 和更多測試矩陣，但進展緩慢，畢竟這是一個社區驅動的項目

第三，也是很關鍵的一點，標準提高了。 以前類似的問題可能就等到下個季度例行發布時一起修，但現在 PostgreSQL 的用戶基數和關鍵程度今非昔比，社區對質量的容忍度更低了，更傾向于快速發布修復。 所以 out-of-cycle 增多，某種程度上也反映了社區對用戶負責的態度：發現問題不拖著，盡快修。這其實是好事。

老馮覺得，連續三年栽在坑里，原因是一個結構性矛盾：安全修復的封閉開發流程 vs. 日益復雜的代碼庫和測試需求。 但好在 PostgreSQL 畢竟是世界上最流行的開源數據庫。因此，即使在開發階段的測試有缺陷，也能很快地在生產環境中通過冒煙眾測被發現。

另一個啟示是 —— 通常我們認為升級小版本是足夠安全的，但顯然，這幾次號外版本的發布也在提醒我們：追新有風險。數據庫老司機當然無所謂，但對于普通用戶來說，在沒有 CVE，惡性 bug 的前提下，說不定還是滯后兩個小版本使用更為穩妥。

References

[1]: https://www.postgresql.org/message-id/19406-9867fddddd724fca@postgresql.org
[2]: https://www.postgresql.org/message-id/349f9c82-3a8b-48ad-8cc4-fe81553793dd%40iki.fi

數據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403