2026-06-20 — ClickHouse 十週年、pgAdmin v9.16 修七個 CVE、Redis 論 Agent 記憶架構

ClickHouse 開源十週年：從單一提交到 2,632 名貢獻者的工程歷程

ClickHouse Blog · 2026-06-19

2026 年 6 月 19 日，ClickHouse 官方部落格發表了一篇回顧文章，標誌著該專案開源整整十年。ClickHouse 是一款以 C++ 為主體（佔程式碼庫 70.7%）的欄式即時分析資料庫，目前穩定版本為 v26.4.4.38-stable（發布於 2026-06-08），GitHub 累計 48,100 顆星、242,070 次提交、799 個正式版本。

核心工程設計：system.contributors

文章以彩繪玻璃為比喻，將開源社群的分散貢獻類比為各自獨立的玻璃碎片，透過共同的基礎設施（鉛條框架）結合成完整作品。最能體現這一哲學的工程決策，是將 system.contributors 資料表直接內建於產品之中。這張系統資料表列出所有曾提交程式碼的貢獻者，可用標準 SQL 查詢：

SELECT * FROM system.contributors ORDER BY name;

在 2026 年 Open House San Francisco 活動中，當時的建置版本已包含 2,632 名貢獻者。相較於將致謝放在外部文件或網站，這種設計讓認可成為系統可查詢資料的一部分，而非靜態的說明文字。

社群規模與 GitHub 指標

文章引用 GitHub Archive 的公開事件資料（分析期間：2025 年 4 月，11,000 筆公開事件），量化 ClickHouse 社群的活躍程度。截至 2026 年 3 月 19 日，儲存庫累計 Issue 與 Pull Request 總數突破 100,000 件。

項目	總數	關閉率
Issues	27,600	83%（23,016 件）
Pull Requests	71,284	99%（70,362 件）

99% 的 PR 關閉率在大型開源專案中屬於顯著高水準，意味著絕大多數提交都被合併或有明確的後續處理，而非長期擱置。

實際效果：cBioPortal 癌症基因組學案例

cBioPortal 是由紀念斯隆凱特琳癌症中心（MSK）維護的癌症基因組學平台，以 ClickHouse 承擔高複雜度的過濾查詢。將複雜過濾邏輯下推（pushdown）至 ClickHouse SQL 層後，原本需要數分鐘的查詢縮短至秒級，達到約 10 倍的效能提升。這個案例說明欄式儲存結合大規模向量化執行對生物醫學分析工作負載的實際價值，也展示了社群外部貢獻如何直接影響核心產品路線圖。

版本演進：v25.5 與 v26.5 的貢獻者快照

文章以 v25.5 與 v26.5 兩個版本的 system.contributors 快照為對比，展示一年間新增的貢獻者數量。這種版本間差異分析使貢獻成長具備了可量化、可重現的追蹤機制。ClickHouse 採用年度兩位數版本號策略（如 26.x 代表 2026 年），每個次版本對應獨立的功能集合，讓貢獻者加入的時間點可直接對應至具體功能週期。

原始來源：ClickHouse Blog — Ten years of open source: a stained-glass view

pgAdmin 4 v9.16 發布：七個 CVE 修復與 64 項功能變更

PostgreSQL News · 2026-06-19

2026 年 6 月 19 日，pgAdmin 4 發布 v9.16，共包含 64 項錯誤修復與新功能，並一次性修補了 7 個安全漏洞（CVE-2026-12044 至 CVE-2026-12050）。此版本同時宣告 pgAgent 進入棄用流程，並將 SQL 範本的最低支援版本重新基線（rebase）至 PostgreSQL 14。

安全修復：七個 CVE 的技術細節

本次發布修復的七個 CVE 涵蓋 SQL injection、XSS、未授權存取與開放重定向等多類別漏洞，集中反映了 pgAdmin 作為 Web 應用程式的攻擊面。CVE-2026-12044 是影響範圍最廣的 SQL injection，存在於 16 個對話框範本的 COMMENT ON 語句中。

CVE-2026-12044 — 16 個對話框範本中 COMMENT ON 語句的 SQL injection
CVE-2026-12045 — AI Assistant 繞過唯讀交易限制
CVE-2026-12046 — SQL Editor 端點缺少身份驗證裝飾器（authentication decorators）
CVE-2026-12047 — 雲端部署模組的 HTML injection
CVE-2026-12048 — 伺服器錯誤文字與 Explain 計劃中的 Stored XSS
CVE-2026-12049 — 多重驗證（MFA）流程中的 Open Redirect
CVE-2026-12050 — 命名還原點（named restore point）端點的 SQL injection

值得注意的是，此版本同步移除了伺服器存取輔助函式中的 administrator-role 繞過邏輯，該問題雖未被分配 CVE 編號，但屬於權限控制缺陷的根本性修正。

核心改動：功能新增與架構調整

伺服器色彩標記（Server Color Coding）功能讓管理員可依連線伺服器的顏色設定，自動為面板與分頁標頭上色，降低在多環境（開發／測試／生產）切換時的誤操作風險。此功能對於同時管理多個 PostgreSQL 實例的 DBA 有直接的可用性意義。

Materialized View 對話框新增了對 TOAST tuple target 儲存參數的支援，允許使用者在 GUI 層設定欄位的 TOAST 策略，無需手動執行 ALTER TABLE。Helm chart 方面，init container 的 containerSecurityContext 現在可透過 values 檔案配置，方便在受限的 Kubernetes 環境中部署。

相依性更新與 SQL 範本基線調整

此版本將 Electron 更新至 42.3.3，加密套件 cryptography 升至 49.0。SQL 範本的目標版本重新基線至 PostgreSQL 14，正式終止對 PostgreSQL 13 及更早版本的 GUI 支援。考量到 PostgreSQL 13 已於 2025 年 11 月進入 EOL（End of Life），此調整與上游社群的版本週期策略保持一致。

pgAgent 棄用時程

pgAgent 是 pgAdmin 長期內建的作業排程模組，v9.16 正式宣告其棄用時程：網站上的相關下載連結將在一個月內移除，pgAdmin 對 pgAgent 的功能支援預計在約六個月後停止。官方建議使用者遷移至 pg_cron 或其他外部排程解決方案。pgAdmin 4 v9.16 提供 Windows、macOS、Python Wheel、Docker Container、RPM、DEB 及原始碼 tarball 等多種格式。

原始來源：PostgreSQL News — pgAdmin 4 v9.16 Released

擴大 Context Window 無法解決 Agent 記憶問題：Redis 的記憶體架構分析

Redis Blog · 2026-06-17

Redis 官方部落格於 2026 年 6 月 17 日發表技術文章，指出當前 AI agent 開發中一個常見的架構誤解：將 context window 大小等同於 agent 記憶能力。文章結合兩篇學術研究（Lost in the Middle 與 NoLiMa benchmark）以及實際 token 成本數據，論證記憶持久化是基礎設施問題，而非模型參數問題。

原本的問題：Context Window 的兩個根本限制

Context window 是每次 LLM API 呼叫時的輸入緩衝區，每次呼叫皆從空白狀態讀取；agent 記憶則指跨 session 的持久化系統，兩者在設計層次上不同。單純擴大 window 尺寸無法建立跨 session 的狀態連續性。

第一個限制來自注意力分布不均。「Lost in the Middle」研究顯示，模型對 context 頭尾的注意力顯著高於中間段，當答案位於長 context 的中段時，GPT-3.5-Turbo 的表現甚至低於零樣本基線。NoLiMa benchmark 對 13 個宣稱支援 128K+ token 的主流模型進行測試（包括 GPT-4o、Claude 3.5 Sonnet、Llama 3.3 70B 等），採用「最小詞彙重疊」設計，要求模型透過潛在關聯推理定位答案，而非關鍵字比對：

Context 長度	達到短 context 50% 效能的模型數
1K tokens 以下	13/13（基線效能 80–99%）
32K tokens	僅 2/13

多數模型的有效 context 長度（effective context length）僅維持在 2–8K tokens，遠低於其宣稱的 128K 上限。GPT-4o 在 32K tokens 時從 99.3% 基線降至 69.7%；Llama 3.3 70B 則從 97.3% 跌至 42.7%。

採用的方法：三層記憶架構與選擇性檢索

文章提出以外部持久化層替代「堆疊完整歷史」的做法，將 agent 記憶拆分為三個層次：

短期記憶（Short-term）：當前 session 的 context window，session 結束後清除
工作記憶（Working memory）：context window 加上即時檢索的相關片段
長期記憶（Long-term）：跨 session 的外部資料庫，透過向量搜尋按需檢索

核心模式是「選擇性檢索」而非「全量注入」：

/* 建議模式 */
Agent 呼叫 → 從長期記憶取出相關片段 → 注入 window → 呼叫 LLM

/* 避免模式 */
Agent 呼叫 → 將完整歷史記錄注入 window → 呼叫 LLM

LLM API 為無狀態設計，每次呼叫須重送完整對話歷史，輸入成本隨對話長度線性增長，累計成本則呈二次方增長，在 agentic 工作負載（多次呼叫、狀態持續累積）下尤為顯著。

實際效果：Redis 方案的量化結果

文章引用兩項研究數據，對比記憶體增強（Memory-Augmented）與全量 context 兩種方式的效能差異。選擇性檢索在大幅削減 token 用量的同時，準確率反而超越直接塞入完整 context 的做法。

方法	準確率 / 延遲	Token 消耗
Memory-Augmented（方案一）	81.95% 準確率	每次查詢約 1,294 tokens（全量的 ~5%）
Memory-Augmented（方案二）	p95 延遲降低 91%	每次對話 1,764 tokens vs. 全量的 26,031 tokens
全量 context 方式	基線	26,031 tokens / 對話

Redis 的開源工具 agent-memory-server 實作了上述架構，支援 Model Context Protocol（MCP）整合與可配置的 LLM provider。商業產品 Redis Iris 則提供兩層記憶設計：短期記憶以 in-memory 資料結構實作，長期記憶透過向量搜尋（Redis Search）實作，操作狀態以 Hash 與 JSON 資料型別儲存，語意快取（Redis LangCache）則用於降低重複推理的 token 開銷。記憶層的設計使其與底層模型或 window 尺寸解耦，LangGraph 的資料庫無關 checkpointing 機制也採用類似策略，確保狀態在模型切換後仍能保留。

原始來源：Redis Blog — Why a bigger context window won't fix your agent's memory · NoLiMa Benchmark (arXiv:2502.05167) · Lost in the Middle (ACL Anthology)

End of article