Postgres 命令列工具中 Ctrl-C 取消查詢的機制極其敷衍且充滿漏洞

背景

在 PostgreSQL 的日常操作中，使用 Ctrl-C 取消執行中的查詢是開發者習以為常的動作。然而，這項看似簡單的功能背後卻隱藏著長達三十年的設計缺陷：psql 客戶端透過建立一個全新的、且完全不加密的連線來發送取消請求，這不僅存在競態條件的風險，更可能導致中間人攻擊或阻斷服務攻擊（DoS）。

社群觀點

針對 PostgreSQL 這種「帶外」（out-of-band）的查詢取消機制，Hacker News 的討論聚焦於其架構設計的歷史成因與安全性權衡。部分開發者原本期待看到的是伺服器內部如何清理記憶體或中斷執行緒的底層細節，但討論隨即轉向了網路通訊協定的實作邏輯。

有網友質疑，為何 PostgreSQL 不直接在現有的 TCP 連線中發送取消指令，而必須大費周章另開新連線。對此，資深開發者解釋這與 PostgreSQL 傳統的請求處理模式有關：伺服器通常遵循「讀取請求、執行任務、回傳結果」的線性流程。若要在同一連線中處理取消請求，意味著伺服器在執行繁重查詢時必須不斷輪詢（poll）連線狀態，這會大幅增加網路層的複雜度，且必須處理管線化請求的緩衝問題。相較之下，另開連線雖然顯得有些笨拙，卻避開了複雜的網路狀態同步。

討論中也提到了其他資料庫的實作方式作為對比，例如 MSSQL 就在現有連線中使用特殊的訊息格式來達成目的。此外，有觀點指出 TCP 協定本身其實具備「緊急資料」（Urgent Data）功能，這在早期的 Telnet 時代常用於處理 Ctrl-C 指令，理論上可以繞過發送緩衝區直接由伺服器優先接收，但在現代資料庫實作中已鮮少見到這種做法。

對於安全性隱憂，社群中存在兩極看法。一方認為 psql 至今仍預設以明文發送取消請求確實令人不安，特別是在開放式網路環境下，攻擊者只需攔截到連線金鑰，就能反覆重放請求來癱瘓特定連線。但另一方則持現實主義觀點，認為如果資料庫的網路層級已經暴露給不被信任的來源，那麼未加密的取消請求可能只是眾多嚴重安全漏洞中最微不足道的一個。這種「防禦縱深」的缺失，反映了 PostgreSQL 在開發初期更側重於內部網路環境的穩定性，而非現代網際網路的極端安全需求。

延伸閱讀

在討論中，開發者提到了微軟對於 SQL Server 協定的實作文件，詳細說明了其如何透過 TDS 協定在現有連線中處理取消訊息。此外，文章作者也推薦了其開發的開源工具 Elephantshark，這是一款專門針對 PostgreSQL 網路流量進行監測的代理工具，功能類似於 Wireshark 但更專注於資料庫協定的解析。