对于经常使用 psql 的开发者而言，Ctrl-C 取消一个长时间运行的查询已经成为肌肉记忆。当你在终端按下这个组合键，看到「Cancel request sent」和随后的「ERROR: canceling statement due to user request」时，你可能从未想过这背后发生了什么。然而，这个看似简单的操作背后隐藏着一套令人惊讶的「hack-y」机制，正在逐步演变成 PostgreSQL 生态中不可忽视的技术债务。
取消请求的工作机制与设计取舍
当你按下 Ctrl-C 时，psql 并不会通过现有的数据库连接发送取消信号，而是创建一个全新的 TCP 连接到服务器。这个新建连接使用一个特殊的协议版本号来标识自己。标准的 PostgreSQL 协议是 3.2，而取消请求使用魔数 1234.5678 来区分。连接建立后，客户端仅发送目标后端的进程 ID 和一个密钥，服务器据此识别需要取消的会话。
这种设计源于 PostgreSQL 的核心架构：每个后端进程是单线程的，当它正在执行查询时，无法同时监听网络套接字上的新数据。如果在现有连接上发送取消请求，该请求会排队等待在客户端到服务器的任何在途数据后面。在最坏的情况下，TCP 缓冲区已满，客户端甚至无法发送取消请求。因此，PostgreSQL 选择了一条独立的路径来绕过这个问题，但这也带来了竞态条件：取消请求是针对整个连接的，而非针对某个特定的查询。
明文传输的安全隐患
真正的问题在于，这个取消请求在网络上几乎是「裸奔」的。即使主连接使用了最严格的 TLS 配置，psql 始终以明文方式发送取消请求。这意味着任何能够监听网络流量的人都可以看到进程 ID 和取消密钥。攻击者拦截到取消请求后，可以对该连接上的任何未来查询发起拒绝服务攻击，只需不断重放这个拦截到的取消令牌即可。更糟糕的是，PostgreSQL 18 之前使用 4 字节的密钥，这使得暴力破解变得切实可行。
虽然 PostgreSQL 18 已将协议升级到 3.2，支持长达 256 字节的密钥，但 libpq 和 psql 仍然默认使用旧版协议，除非显式指定 min_protocol_version=3.2。值得注意的是，PostgreSQL 17 已经在 libpq 中引入了加密取消请求的函数，但 psql 本身至今仍未采用这些新接口。这是因为新函数不是异步信号安全的，要在信号处理程序中调用 TLS 握手代码会带来复杂性。一个补丁正在提交审核中。
从技术债务角度看架构困境
这个取消机制揭示了更深层次的架构困境。PostgreSQL 的进程 - per - 连接模型是二十多年前的设计决策，当时线程支持尚不完善，且网络环境相对可信。在那个时代，用独立连接发送取消请求、使用 4 字节密钥、快速取消查询而不影响其他连接 —— 这些都是合理的工程折衷。然而，时至今日，这些假设已经不再成立。
现代数据库系统采用不同的方案：在现有连接上发送特殊消息，通过多路复用实现查询取消。这要求服务器端有专门的线程或协程来处理中断信号。但要在 PostgreSQL 中实现这种模式，需要对后端架构进行重大重构。社区选择了渐进式改进：先在协议层面支持更长的密钥，再逐步实现加密传输。
当前可行的缓解措施与改进方向
作为用户，可以采取一些措施来降低风险。首先，确保使用 PostgreSQL 18 并在连接字符串中添加 min_protocol_version=3.2。其次，考虑使用 VPN 来保护网络流量。对于安全性要求极高的场景，可以避免在 psql 中使用 Ctrl-C，转而通过另一个终端手动执行 pg_cancel_backend ()。
从生态系统角度看，PostgreSQL 社区正在多个层面推进改进。协议层面已经支持更长的密钥和加密取消请求；libpq 层面提供了新的 API 函数。然而，这些改动需要谨慎推进，因为任何对取消机制的修改都可能影响现有的数千个客户端驱动和工具。
PostgreSQL 的 Ctrl-C 取消机制是一个典型的技术债务案例：它在特定历史条件下设计良好，但随着时间推移和安全需求的提升，逐渐暴露出架构层面的局限。明文传输、4 字节密钥、连接级别的取消而非查询级别的取消 —— 这些问题单独看都不严重，但累积起来构成了不可忽视的风险。社区已经意识到这些问题并在稳步推进改进。作为使用者，了解这些底层细节有助于在关键场景中做出更安全的选择。
资料来源：本文技术细节主要参考 Neon 博客的技术分析文章「Ctrl-C in psql gives me the heebie-jeebies」以及 Hacker News 上的社区讨论。