在使用 psql 执行长时间查询时，按下 Ctrl-C 能让查询中断并返回控制权。这个看似简单的操作背后，实际上涉及 PostgreSQL 一套精心设计的独立控制协议。理解这一机制不仅有助于排查「取消请求发送了但查询仍在运行」的困惑场景，还能在生产环境中更精准地处理超时与中断逻辑。
独立控制连接的设计动机
PostgreSQL 的查询取消机制并非简单地在线程之间发送信号。当用户在 psql 中按下 Ctrl-C 时，客户端并不会直接向当前已建立的数据库连接发送中断请求。原因在于：当前连接可能正处于阻塞状态，无法及时响应任何新增的协议消息。为此，psql 会创建一个独立的控制连接来发送取消请求。
这套设计的关键在于 PGcancelConn 与 PGconn 的分离。PGcancelConn 通过 PQcancelCreate() 从现有的数据库连接中衍生而出，但它拥有自己的 socket 描述符和连接状态。这种设计确保了取消请求可以在任何时刻发起，而不必依赖原连接的可响应状态。根据 PostgreSQL 官方文档，原始连接中指定的 sslmode、gssencmode 等安全参数会被完整继承到取消连接中，以保证加密通信的一致性。
取消请求的发送与轮询机制
一旦 PGcancelConn 创建完成，客户端可以选择阻塞或非阻塞两种方式发送取消请求。PQcancelBlocking() 会同步等待请求发送完成，而 PQcancelStart() 配合 PQcancelPoll() 则允许应用程序在等待过程中执行其他任务。后者需要开发者手动管理 socket 的可读 / 可写状态，并在每次轮询后检查返回状态是否为 PGRES_POLLING_OK 或 PGRES_POLLING_FAILED。
值得特别注意的是：取消请求的成功发送并不等同于查询一定会被中断。如果服务器端已经完成了查询处理，客户端的取消请求将无处可去，不会产生任何可见的结果。只有当服务器仍在处理该查询时，取消请求才会设置一个标志位，最终导致查询提前终止并返回错误结果。
服务端的协作式中断原理
服务端收到取消请求后，并不会立即强行终止正在执行的查询进程。PostgreSQL 采用的是协作式中断模型：后端进程在执行查询的各个阶段会周期性检查 QueryCancelPending 标志。一旦检测到该标志被设置，查询会尽可能在下一个「安全点」中止执行。
这种设计背后的考量是数据一致性。PostgreSQL 的后端进程在执行查询时会持有各种锁、修改共享内存结构或正在写 WAL 日志。如果在任意位置强制中断，可能导致锁未释放、磁盘文件损坏或复制状态不一致。因此，查询取消被设计为「友好」的中断：后端会在检查点、安全的代码路径处响应取消请求。这意味着如果查询正处于一个长时间且没有中断检查的 I/O 等待中，取消请求可能需要等待更长时间才能生效。
实际工程中的参数与监控要点
在生产环境中处理查询取消时，以下参数和监控点值得关注。首先，connect_timeout 参数在取消连接的轮询过程中会被忽略，应用程序需要自行实现超时逻辑来判断取消请求是否等待过久。其次，如果常规的取消操作无效，可以从另一个会话执行 pg_cancel_backend(pid) 尝试更直接的信号发送；在极端情况下，pg_terminate_backend(pid) 会强制终止后端进程，但这可能导致事务回滚或连接中断。
监控层面建议关注 pg_stat_activity 视图中的 state 和 query 字段。当发现某个后端长时间处于 active 状态且无法通过取消请求终止时，可能需要人工介入检查底层原因，例如是否卡在系统级 I/O、文件系统锁或外部资源等待中。
理解 PostgreSQL 查询取消协议的协作式特性，有助于在设计数据库客户端超时策略时做出更合理的决策：既不过度依赖即时中断，也不必因短暂的「取消延迟」而误判系统异常。
资料来源：PostgreSQL 官方文档 32.7 节《Canceling Queries in Progress》