天下武功，唯快不破。2026年2月13日，今天早上，PostgreSQL 社區例行發布了 18.2 / 17.8 / 16.12 / 15.16 / 14.21 五個小版本。 同一天，據我所見全球范圍內給出生產級支持的只有兩家：AWS RDS，Pigsty。（當然EDB本身發包也算）

一個開源獨立項目，在交付速度上站到了和全球最大云廠商以及 PG 老大哥站在同檔速度線上。這件事本身就是我想用 v4.1 講的故事。

為什么"快"是最重要的能力

做數據庫發行版這幾年，我越來越清楚一個道理：用戶不缺功能，缺的是信任。

信任從哪來？不是 PPT 上寫了多少特性，而是在關鍵時刻你能不能兌現。PostgreSQL 每次小版本更新，往往帶著 bugfix、穩定性修正、安全修補 —— 這些不是錦上添花，而是亡羊補牢。你跟進慢一天，用戶就多暴露一天。

很多發行版的節奏是這樣的：上游發布后做做內部測試，打包構建，最后兩個月過去，發個博客說 “我們現在支持 PG 新版本了”。 等到那個時候，真正著急的用戶早就自己手動升級了 —— “支持” 變成了事后追認，而不是事前保障。

我想做的恰恰相反：讓"跟進"這件事，快到用戶根本不需要自己操心。你看到 PostgreSQL 發了新版本，打開 Pigsty，發現已經準備好了 —— 這才是一個發行版應該給用戶的體感。

所以 v4.1 的主線不是堆新特性，而是把"快速跟進 + 穩定交付"變成一種可持續的常規能力。這個能力才是護城河，因為它考驗的不是某一次的沖刺，而是日復一日的工程紀律。

不止 PostgreSQL：OS 小版本也一起走

做 “快” 容易，又好又快可不容易，這次不僅是 PostgreSQL 的小版本升級，還同步推進了幾個 Linux 操作系統發行版的小版本升級：

?EL：9.6/10.0 → 9.7/10.1?Debian：12.12/13.1 → 12.13/13.3

十四個主流 Linux 發行版的最新小版本，都制作好了對應的離線軟件包。

這里有個必須再次講清楚的事情：

EL 9.7 / 10.1 的離線包與 EL 9.6 / 10.0 不通用。

我知道很多用戶的部署環境是內網甚至完全離線的。遇到這種包版本不匹配的情況，走在線安裝就可以了。

Pig Agent-Native CLI：讓工具學會"自我介紹"

舉個例子：你讓 Claude Code 幫你在三臺機器上裝 PostgreSQL 18 與一堆擴展， 它調用 pig 的時候不需要你手寫任何 prompt 來解釋 pig 怎么用 —— 因為 pig 會自己告訴它。這就是 Agent-Native 的意思。

傳統 CLI 工具的設計假設是 “有個人在看屏幕”，所以它輸出彩色文字、畫表格、顯示進度條 —— 這些對人很友好，但對 Agent 來說全是噪音。Agent 需要的是三件事：

我 Agent-Native 這個概念，很多人覺得這只是個 buzzword。但pig 1.1.0里我做的事情非常具體 —— 核心就一個詞：內自省。

什么意思？傳統 CLI 工具的設計假設是"有個人在看屏幕"。所以它輸出彩色文字、畫表格、顯示進度條 —— 這些對人很友好，但對 Agent 來說全是噪音。Agent 需要的是：

?能干什么—— 工具主動暴露自己的能力列表，而不是讓 Agent 去猜或者去讀文檔。?干了什么—— 執行結果是結構化的 JSON/YAML，而不是一坨需要正則解析的文本。?暴露上下文—— 環境信息可以被程序化地獲取和傳遞。

這三件事聽起來簡單，但要做好需要重新審視 CLI 的每一個子命令。pig 1.1.0把 JSON/YAML 從"附屬輸出格式"提升為 “一等公民”，讓每個操作都能被機器可靠地調用和解析。

坦白說，這個需求我只是提出了理念并參與了設計討論，剩下的實現工作都是由 Codex 和 Claude Code 完成的，我負責最后驗收。所以這也算是 Pigsty 里第一個真正意義上的 AI 原生項目。

AI Coding：不是寫代碼，是掃盲區

v4.1 開發周期里，我在pigCLI 和pg_exporter上投入了大量精力。同時密集使用了 AI coding 工具做復查 —— 主要是 Claude Code 和 Codex 5.3 Extra High。

但我想說的不是"AI 多厲害"，而是 AI 在工程實踐中真正好用的那個點在哪里。

答案是掃盲區。

一個成熟項目里，最危險的 bug 往往不是邏輯錯誤 —— 那種你寫完就知道不對。最危險的是那些"看起來沒問題、跑起來沒問題、但在特定邊界條件下會出問題"的細節。 比如一個指標的單位在 PG17 和 PG18 里不一樣，比如一個io_method參數的版本條件寫成了>= 17但實際上應該是>= 18。

這類問題，人工 review 非常容易漏 —— 因為你的眼睛會自動跳過"看起來對"的代碼。 但 AI 不會。它會老老實實地把每一行都過一遍，尤其在你明確告訴它"幫我檢查版本守衛條件"的時候。

這輪掃下來，我額外修掉了大約十幾到二十個小問題。單獨看每個都不大，但累積起來就是用戶體驗的差距。

這里要特別感謝社區貢獻者 @l2dy[1]，他提了很多高質量 issue， 幫我把 Grafana 儀表盤還有配置細節里一批細節問題集中收斂掉了。 開源項目能不能越做越扎實，靠的就是這種愿意認真摳細節的人。

防火墻默認策略：寧可多敲一條命令

最后講一個看起來很小、但我認為很重要的改動。 在 v4.0 里，我把防火墻默認模式設成了none—— 意思是 “完全不碰你的防火墻配置”。 初衷是好的：尊重用戶現有環境，不做多余的事。但實際反饋告訴我，這個決定有問題。

問題出在哪？EL9 系列默認是開著 firewalld 的，但很多用戶對自己的防火墻狀態并不清楚。 當 Pigsty 選擇"不碰"的時候，用戶以為一切正常，結果發現內網流量不通，排查半天才發現是防火墻規則沒配對。這比 Pigsty 主動配置防火墻帶來的 “干預感” 要糟糕得多。

所以 v4.1 我把默認模式改回了zone，規則非常簡單：

?內網網段默認信任?公網默認只開放三個端口：22（SSH）、80（HTTP）、443（HTTPS）?數據庫端口5432不再默認暴露在公網

如果你需要對外開放數據庫端口，需要自己顯式添加。我知道這會讓某些場景多敲一條命令，但我的判斷是：對于安全相關的默認值，保守永遠好過激進。 把“開放”變成一個有意識的動作，而不是一個容易遺忘的默認值。

七個新擴展，總數來到 451

每個版本照例更新擴展生態，這次新增 7 個，總數到451。幾個值得關注的：

?pg_track_optimizer0.9.1：自動追蹤和推薦索引優化，這個方向一直有人問。?nominatim_fdw1.1.0：OpenStreetMap 地理編碼的外部數據包裝器，GIS 用戶會喜歡。?pg_utl_smtp1.0.0：從數據庫里直接發郵件，Oracle 遷移用戶的老朋友了。?pg_strict1.0.2：嚴格模式擴展，避免不帶條件的 UPDATE/DELETE

同時 TimescaleDB 升到 2.25.0，citus 14.0.0 正式發布，還有一個非常強大的數據匿名化擴展 Postgres Anonymizer 發布了 3.0 —— 都是每個領域的重要更新。

其他值得一提的改動

簡單列幾個我覺得有價值但不值得單獨成章的改動：

autovacuum 閾值調優：把oltp/crit/tiny模板的autovacuum_vacuum_threshold從 50 提到 500，analyze_threshold從 50 提到 250。原因是小表在默認閾值下會被高頻 vacuum/analyze，造成不必要的 IO 開銷。這個改動對有大量小表的場景（比如多租戶系統）會有明顯改善。

文件描述符上限統一：修復了fs.nr_open和LimitNOFILE的層級關系，統一設為 8M。之前有用戶在高并發場景下遇到 FD 耗盡，排查發現是內核參數和 systemd 配置不一致導致的。

checkpoint_completion_target：從 0.90 提到 0.95。這個參數控制 checkpoint 寫入的平滑程度，0.95 能更好地分散 IO 壓力，減少 checkpoint 期間的性能抖動。

Vibe 調整：Jupyter 默認關閉（大多數人不用），Claude Code 改為通過 npm 包統一管理（之前的安裝方式不夠干凈）。

infra-rm 重構：卸載邏輯新增deregister分段清理，不再是一把梭全刪。你可以更精細地控制卸載的范圍和順序。

新增 Mattermost 應用模板：一鍵部署 Mattermost，包含數據庫、文件存儲、反向代理的完整配置。適合需要自建團隊通訊工具的場景。如果你覺得 QQ/微信接入 ClawdBot 太麻煩，為什么不自己搭建一個 IM 呢？

v4.1 不是一個大版本。沒有架構重寫，沒有新模塊登場。但它證明了一件事：上游發布當天即可交付生產級支持，這個速度不是偶然的沖刺，而是一種可以持續兌現的工程能力。 開頭說用戶缺的是信任。信任不是一次建立的，而是每一次小版本發布時你都在那里，每一次安全修補你都沒有缺席。v4.1 想做的，就是把這件事再證明一次。

以上是 v4.1 的核心思路和重點改動。下面附完整的版本提交注記和技術細節，方便按需查閱。

數據庫老司機

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

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

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