pg_durable：Microsoft 開源的 PostgreSQL 原生持久執行擴充套件
GitHub · microsoft/pg_durable · 2026-06-06
Microsoft 以 PostgreSQL License 開源 pg_durable，一個讓 PostgreSQL 直接支援長時間運行、可容錯 SQL 函數的擴充套件，目標是消除傳統工作流中「cron job + worker process + 消息佇列 + 狀態追蹤表」的分散式拼湊方案。目前支援 PostgreSQL 17 和 18，以 Rust（nightly）+ cargo-pgrx 建置，以 Preview 狀態發布。
pg_durable 解決的問題
長時間運行的後台工作流在現有架構中面臨幾個系統性問題：重啟後已完成的步驟會被重複執行（缺少 checkpoint）；工作流狀態分散在 SQL、worker 進程和應用程式碼中（維護困難）；長事務持有鎖並使 WAL 日誌膨脹；以及狀態追蹤依賴 ad-hoc 表格（難以可見性觀測）。pg_durable 透過在 PostgreSQL 內部維護執行狀態，讓工作流在崩潰後能從最後一個 checkpoint 恢復，而非從頭重新執行。
架構與 SQL DSL
pg_durable 的核心機制是三個元件：（1）SQL DSL——以 ~>（串接）和 |=>（批次）運算符在 SQL 中組合工作流步驟；（2）checkpoint——執行時期在每個步驟後將狀態持久化到 PostgreSQL；（3）確定性重播——崩潰後從最後一個 checkpoint 確定性地恢復執行。一個最小範例：
SELECT df.start(
'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
~> 'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);控制流 API 包含 df.if()（條件）、df.join()（平行合併）、df.loop()（迴圈）與 df.http()（外部 API 呼叫）。執行狀態與歷史可直接從 df.instances 和 df.nodes 視圖查詢，不需要外部監控工具。
影響範圍
pg_durable 最適合的工作負載是那些「狀態已在 PostgreSQL 中」的場景：向量 embedding pipeline（分塊、嵌入、upsert）、資料攝取管道（暫存、去重、轉換、發布）、計劃性維護（偵測膨脹、通知、批准、執行）、fan-out 聚合查詢。對於需要任意應用程式碼、非 HTTP SDK、或豐富的記憶體控制流的場景，pg_durable 的 SQL 形狀 DSL 會是限制，需要將邏輯封裝為 SQL 函數或透過 df.http() 暴露，或退回使用 Temporal、AWS Step Functions 等通用編排器。
Bundler Cooldown：讓新發布的 Gem 先等待審查的供應鏈防護機制
RubyGems Blog · 2026-06-03
Bundler 4.0.13 引入 Cooldown 功能，一個基於時間的依賴解析過濾器，在 Gem 版本發布後 N 天內拒絕解析到該版本。其設計目標是關閉供應鏈攻擊的時間視窗：攻擊者在入侵帳號後發布惡意版本，任何在這段時間內執行 bundle install 的開發者都會直接安裝到惡意套件，而 Cooldown 讓這個視窗從「幾分鐘內立即傳播」變成「需等待 N 天才能解析」。
機制設計
Cooldown 讀取 RubyGems.org v2 compact index 中每個 Gem 版本的 created_at 時間戳記，將其與設定的等待天數比較，拒絕解析過新的版本。機制完全透明：Cooldown 只拒絕可以確定「太新」的版本；對於沒有時間戳記的版本（舊伺服器、使用 v1 格式的私有 registry），保持正常解析，不會誤拒。
Cooldown 在 Gemfile 中逐 source 宣告：
source "https://rubygems.org", cooldown: 7設定優先順序為：命令列 flag（--cooldown 0）> 全域設定 > per-source 宣告。現有 lockfile 完全不受影響——新增 Cooldown 不會干擾已鎖定的版本，只在執行新的解析時（bundle install、bundle update）生效。
影響範圍
Cooldown 的限制在於它只保護「啟動期間的意外升級」場景，不能防止開發者主動要求安裝特定新版本（可用 --cooldown 0 覆蓋）。對於緊急安全修補，降低 cooldown 天數或直接覆蓋是正常操作路徑。此功能是針對帳號被入侵後的惡意發布場景，對依賴混淆攻擊（dependency confusion）或 typosquatting 等其他供應鏈攻擊向量不提供保護。
原始來源：RubyGems Blog