PostgreSQL 19 新增 WAIT FOR：非同步複本上的讀寫一致性
ClickHouse Blog（作者為 PostgreSQL 貢獻者） · 2026-08-25
ClickHouse 官方部落格於 2026-08-25 刊出文章，說明 PostgreSQL 19 新增的 WAIT FOR 指令。這是一個新的 SQL 命令，讓連線阻塞至 WAL 重播到指定 LSN 為止，藉此在非同步複本上取得讀寫一致性保證。
背景
在非同步複製下，主庫 commit 後的資料不會立刻出現在複本上，因為複本重播 WAL 有延遲，這使得寫入後立刻查詢複本可能讀到舊值，稱為 read-your-writes 問題。這個需求最早由 Postgres Professional 的 Ivan Kartyshov 在 2016 年於 pgsql-hackers 郵件論壇提出，討論串名為「make async slave to wait for lsn to be replayed」，當時提案稱為 WAITLSN，經過三次修訂後才在 PostgreSQL 19 中定案為 WAIT FOR。
核心改動
WAIT FOR 的語法是 WAIT FOR LSN 'lsn' [WITH (options)]，可搭配 MODE、TIMEOUT、NO_THROW 等選項使用。應用程式在主庫寫入後，先用 pg_current_wal_insert_lsn() 取得目前 LSN，再到複本執行 WAIT FOR 阻塞直到該位置重播完成才讀取。
-- 於 primary 端取得目前 LSN
SELECT pg_current_wal_insert_lsn();
-- 於 standby 端阻塞直到該 LSN 重播完成
WAIT FOR LSN '0/306EE20'
WITH (MODE standby_replay, TIMEOUT 5000);
WAIT FOR 內部不持有任何 snapshot，而是透過 latch 機制阻塞，由 startup process 在重播到達目標 LSN 時發出訊號喚醒，避免因 snapshot 衝突卡住 replay 而造成自我死鎖。
standby_replay（預設）：等到 WAL 重播且資料可讀standby_flush：等到 WAL 寫入複本磁碟standby_write：等到 WAL 寫入複本primary_flush：等到 WAL 寫入主庫磁碟
影響範圍
這讓應用程式能在不開啟同步複製的前提下，針對特定寫入取得一致性讀取保證，避免同步複製對所有寫入路徑造成的延遲成本。
Suprema Gaming 將分析平台由 Snowflake 遷移至 ClickHouse Cloud
ClickHouse Blog · 2026-08-25
ClickHouse 官方部落格於 2026-08-25 發布案例研究，說明拉丁美洲博弈公司 Suprema Gaming 如何將分析平台由 Snowflake 遷移至 ClickHouse Cloud。這篇文章記錄了遷移動機、架構調整，以及遷移後在延遲與成本上的實際數字。
背景
Suprema Gaming 於 2019 年由三位撲克玩家創立，前身為全球最大的 B2B 撲克聯盟 Suprema Poker，目前業務覆蓋 70 多個國家、逾 50 萬名玩家。原本的分析平台建立在 Snowflake 之上，資料經由 S3、SQS 與 Snowpipe 流入，查詢延遲以分鐘計，且 dbt 每日僅完整重建一次，導致資料落後超過 4 小時；每新增一個倉儲或消費者，成本也隨之上升。
採用的方法
為了支援 CEO Fernando Almeida 提出的「agentic-first」願景——讓 AI 代理直接從即時資料回答問題，而非只提供人看的靜態儀表板——團隊將分析平台遷移到 ClickHouse Cloud。即時資料透過 ClickPipes 以 CDC 串流擷取原生來源，不支援的來源則以 Debezium 加 Kafka 補齊，整體可達秒級擷取；dbt 部署改為透過 GitHub Actions 單次執行，不再依賴 Airflow 之類的外部排程工具。
對話式 BI 代理「Senna」服務一般業務使用者，另有 10 個專職代理分別負責資料建模、dbt 開發、驗證與監控，其技能以版本控管的程式碼呈現，代理跑在 EC2 上的 LibreChat，並用 Langfuse 做呼叫追蹤與評估。遷移過程本身也由具備 ClickHouse 直接存取權限的代理協助完成，並搭配角色型存取控制與查詢時 PII 遮罩，確保各消費者僅有最小必要權限。
實際效果
每個指標在切換前都與舊系統逐筆核對，並讓代理端到端比對新舊平台結果、標記差異、反覆校正規則直到兩邊一致，每條校正後的規則同時轉為版本控管的 dbt 測試。遷移後 P95 資料延遲降至約 1 分鐘，直接讀取 marts 的速度比舊方案快 27 倍，倉儲成本下降 62%。
原始來源：ClickHouse Blog
DuckDB 推出純 Java 的 Table Function 建構 API
duckdb.org · 2026-08-25
DuckDB 官方部落格於 2026-08-25 發布文章，介紹 DuckDB Java client 新增的 table function 建構 API。開發者能以純 Java 撰寫 table function，不需要碰觸 C/C++ 擴充。
背景
table function 能把外部資料來源包裝成 SQL 可查詢的表，讓使用者在同一段查詢裡同時存取本地檔案與外部系統，不必先匯出成中繼檔案。過去撰寫 table function 只能透過 C API，需要實作 bind、init、execute 三段生命週期的函式指標（如 duckdb_table_function_bind_t），以 duckdb_table_function_set_name()、duckdb_table_function_add_parameter() 等 setter 逐步建構，再用 duckdb_register_table_function() 註冊，用完後還要手動呼叫 duckdb_destroy_table_function() 釋放資源，對只熟悉 Java 的開發者門檻不低。
核心改動
新 API 以 DuckDBFunctions.tableFunction() 為入口的 builder 模式：呼叫 .withName()、.withParameter()、.withNamedParameter() 宣告名稱與參數，再用 .withFunction() 傳入實作 DuckDBTableFunction 介面的類別，最後呼叫 .register(connection) 完成註冊。該介面要求實作 bind()、init()、apply() 三個方法，分別對應 C API 的 bind、init、execute 三階段，apply() 透過 DuckDBDataChunkWriter 把資料寫入輸出的 vector。
DuckDBFunctions.tableFunction()
.withName("mongo_query")
.withParameter(String.class)
.withParameter(String.class)
.withNamedParameter("columns", String.class)
.withNamedParameter("hostname", String.class)
.withNamedParameter("port", Integer.class)
.withFunction(new MongoQueryFunction())
.register(connection);
影響範圍
因為整段實作留在 JVM 內，例外會被 Java 的例外機制擋下，不會像 C++ 擴充那樣一個 segfault 就讓整個資料庫進程當掉。開發者也能直接重用既有的 Java 生態（JDBC driver、各家官方 SDK）存取外部系統，不必重新實作連線協定；文章以查詢 MongoDB 的 mongo_query table function 為例，並用實作 AutoCloseable 的 DuckDBTableFunctionState 讓資源隨查詢生命週期自動釋放。