pg_re2 上線：RE2 引擎為 Postgres 帶來免回溯正規表示式，並打通 pg_clickhouse 下推
ClickHouse Blog · 2026-07-08
背景
ClickHouse 團隊發布 pg_re2，一款把 Google 開源的 RE2 正規表示式函式庫包裝成 Postgres 擴充套件的專案，目前最新版本為 v0.4.0（2026-07-03 發布，累計 5 個 release）。Postgres 內建的正規表示式引擎採回溯（backtracking）演算法，遇到特定模式（例如巢狀量詞）時執行時間可能隨輸入長度指數成長。RE2 改用有限自動機（finite automaton）逐字元掃描字串，不做回溯，執行時間與輸入長度成線性關係，這也是 Google 當年在 RE2 專案裡強調的「no catastrophic backtracking」保證。
核心改動
安裝方式很單純，需要 GNU make 與 Postgres 開發標頭檔，也可透過 PGXN 取得：跑 make、make installcheck、make install 後執行 CREATE EXTENSION re2; 即可使用。套件要求 Postgres 13 以上版本，並依賴系統已安裝 re2 函式庫與開發標頭。核心函式是 re2match()，語意對齊 ClickHouse 的正規表示式函式，讓同一段 pattern 在兩套系統上得到一致結果。
SELECT id, re2match(by, 'Quake\b')
FROM log.entries WHERE re2match(by, 'Quake\b');ClickHouse 部落格公布的基準測試顯示，re2match() 整體比 Postgres 原生正規表示式快 1.8 倍到 8.6 倍，其中字串擷取（extract）類操作差距最大，達 7.2 倍到 8.6 倍；走索引掃描（index scan）路徑的場景則有 1.1 倍到 1.8 倍的提升。
影響範圍
真正的整合重點在 pg_clickhouse v0.3.0：這個版本新增了 pg_re2 函式的下推（pushdown）支援，讓在 Postgres 端寫的 re2match() 查詢可以直接下推到 ClickHouse 執行，兩邊使用同一套正規表示式語法與比對結果，不必再為兩套引擎各自調整 pattern。對於用 pg_clickhouse 做聯邦查詢的團隊，這代表日誌過濾、字串抽取等常見查詢可以少踩一次語法不一致的坑，也能吃到 RE2 在大量掃描場景下的效能紅利。
PDU 讓打不開的 Postgres 資料庫離線匯出，還能用 WAL 精準復原誤刪資料
PostgreSQL.org News · 2026-07-08
背景
PostgreSQL 官網公告了開源工具 PDU（PostgreSQL Data Unloader），鎖定的情境是資料庫實例已經起不來、SQL 工具完全用不上的災難現場：可能是系統目錄（catalog）損毀、資料檔案受損，或有人不小心跑了 DELETE／UPDATE。PDU 直接讀取 PGDATA 底下的資料檔案與 WAL 歸檔，過程中不寫回、不修改原始目錄，官方將它定位為「緊急救援工具」，而非備份或 PITR（Point-in-Time Recovery）的替代品。專案採 Apache License 2.0 授權，支援 PostgreSQL 14 到 18。
規格細節
PDU 的第一步是離線重建 metadata：不需要啟動 postgres 服務，直接從 PGDATA 解析系統目錄結構。操作上先執行 b; 完成 bootstrap，再用 use <database>;、set <schema>; 切換到目標 schema，即可用 \d+ table_name; 查看表結構。匯出資料則分三個層級，對應單表、整個 schema、或整個資料庫：
unload tab customers; -- 匯出單一資料表為 CSV
unload sch public; -- 匯出整個 schema
unload ddl; -- 產生 DDL 陳述式targeted WAL recovery 是另一半重點功能：針對誤刪或誤改的資料，PDU 直接解析 WAL 歸檔或複本裡的記錄，把刪除前、更新前的 tuple 版本重建出來，而不是依賴 VACUUM 清理前殘留在 heap 裡的舊 tuple 痕跡——這代表即使誤刪操作發生已久、殘留資料早被 VACUUM 清掉，只要 WAL 還在，仍有機會復原。
影響範圍
實際操作上，使用者先用 param restype delete; 或 param restype update; 指定要復原的操作類型，再用 param resmode tx;（依交易 ID）或 param resmode time;（搭配 starttime／endtime 指定時間區間）鎖定範圍，接著 scan <table>; 掃描 WAL、用 restore del <TxID>; 或 restore upd <TxID>; 把目標 tuple 取出。對維運團隊而言，這種不依賴完整重建整個實例、只針對特定表或特定交易做定點復原的能力，補上了「資料庫還沒完全壞掉、但某段資料被誤刪」這類中間狀態的救援手段。
pglayers 用可疊加的 Docker Layer 打包 Postgres 擴充套件，免編譯直接疊上官方映像
PostgreSQL.org News · 2026-07-08
背景
PostgreSQL 官網公告了 pglayers 專案，把 50 多個常用 Postgres 擴充套件各自打包成 FROM scratch 建置的極簡 Docker 映像，每個映像只含必要的共享函式庫、control 檔、SQL 腳本與對應的檔案系統路徑。使用者不用再為了裝一個 pgvector 或 PostGIS 就在容器裡跑 apt-get 或整套編譯工具鏈，而是直接用 COPY --from 把預建好的擴充套件層疊到官方 postgres 映像上。專案採 MIT 授權，支援 linux/amd64 與 linux/arm64 雙架構。
核心改動
疊層的做法直接借用 Docker 多階段建置（multi-stage build）的 COPY --from 語法，把另一個映像的檔案系統內容複製進當前建置階段，不需要該映像本身被執行，也不需要共用建置上下文。基本用法如下，疊幾層就有幾種擴充套件：
FROM postgres:17
COPY --from=ghcr.io/pglayers/pgx-pgvector:17 / /
COPY --from=ghcr.io/pglayers/pgx-postgis:17 / /
COPY --from=ghcr.io/pglayers/pgx-pg_cron:17 / /版本標籤走 pgx-<extension>:<pg_major>（跟隨最新版）或 pgx-<extension>:<pg_major>-<version>（釘死版本）兩種命名，README 列出的版本包含 pgvector 0.8.3、PostGIS 3.6.4、pg_cron 1.6.7、timescaledb 2.28.1、documentdb 0.113-0 等，同時提供一次含齊 50 多個擴充套件的 ghcr.io/pglayers/pglayers-full:17。
規格細節
PostgreSQL 18 新增了兩個 GUC 參數 extension_control_path 與 dynamic_library_path，分別告訴伺服器去哪裡找擴充套件的中繼資料檔（control file）與編譯好的動態函式庫。pglayers 利用這兩個參數，把每個擴充套件放進獨立命名空間 /extensions/<name>/，疊多層也不會互相覆蓋檔案，也讓同一個擴充套件的不同版本可以並存：
FROM postgres:18
COPY --from=ghcr.io/pglayers/pgx-pgvector:18 / /extensions/pgvector/
COPY --from=ghcr.io/pglayers/pgx-pg_cron:18 / /extensions/pg_cron/路徑設定裡保留 $system 與 $libdir 這兩個內建萬用字元，確保 Postgres 原本內建的 contrib 擴充套件不受影響。目前狀態是：
- PostgreSQL 17：穩定支援
- PostgreSQL 18：穩定支援（可用隔離式路徑佈局）
- PostgreSQL 19：實驗性 / beta 支援
對維運與建置 Postgres 映像的團隊來說，這種疊層模式把「裝擴充套件」從一次性編譯動作變成可組合、可快取的 Docker layer，映像瘦身與 CI 建置時間都直接受惠，尤其是 PG18 之後的隔離路徑設計，解決了多擴充套件疊加時常見的檔案覆蓋問題。