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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI Coding：不是寫代碼，是掃盲區(qū)

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

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

答案是掃盲區(qū)。

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

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

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

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

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

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

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

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

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

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

七個新擴展，總數(shù)來到 451

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

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

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

其他值得一提的改動

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

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

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

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

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

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

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

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

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

數(shù)據庫老司機

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

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

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