在日常使用 PostgreSQL 交互式客户端 psql 时，按下 CTRL-C 中断一个长时间运行的查询是最常见的操作之一。然而，这个看似简单的动作背后隐藏着一套精细的协议机制，理解它不仅能帮助开发者更好地掌握 PostgreSQL 的内部运作原理，还能在遇到查询卡死等异常情况时做出更明智的决策。
CTRL-C 的本地拦截机制
当用户在 psql 终端中按下 CTRL-C 时，psql 客户端并不会直接将 Unix 的 SIGINT 信号发送给服务器端的 backend 进程。这一设计背后有着深刻的安全考量：如果允许终端信号直接作用于远程服务器进程，可能导致连接状态不一致甚至数据库损坏。相反，psql 会在本地截获这个组合键，并触发一套名为 CancelRequest 的查询取消协议。
具体流程如下：psql 客户端会打开一条短暂的辅助连接，这条连接使用了连接初始化时服务器返回的密钥信息。通过这条专用连接，psql 向服务器发送一个取消请求消息。服务器端的 postmaster 进程接收到该请求后，会向处理当前会话的 backend 进程发送 SIGINT 信号。整个过程确保了取消请求的发起者具有合法的会话身份，从而避免了恶意中断他人查询的可能。
后端的协作式中断处理
收到 SIGINT 信号后，backend 进程并不会立即在信号处理函数中终止执行。这种设计是有意为之的，因为在信号处理上下文中执行复杂的清理操作极不安全。PostgreSQL 采用了一种协作式的中断机制：SIGINT 处理器仅设置一个全局标志位 QueryCancelPending，然后返回继续执行。正常的服务器代码在执行过程中会周期性调用 CHECK_FOR_INTERRUPTS () 宏，该宏会触发 ProcessInterrupts () 函数的执行。当检测到 QueryCancelPending 标志被设置时，ProcessInterrupts () 会抛出一个特殊的查询取消错误，这个错误会终止当前语句的执行但保留会话连接。
这种设计的优势在于它提供了一种可控的取消方式。查询被取消后，当前事务会根据其状态进行正常的回滚处理，用户会话仍然保持连接，可以继续执行新的查询。这与直接 kill 掉 backend 进程形成了鲜明对比：后者会导致事务状态不确定，可能需要重建连接甚至修复数据库。
不可中断代码与边界情况
然而，协作式中断机制并非万能。如果 backend 进程正在执行一段没有调用 CHECK_FOR_INTERRUPTS () 的代码，例如一个紧密的 C 语言循环或正在读取数据的系统调用，那么取消请求可能会被延迟处理。在极端情况下，如果后端陷入了内核态的系统调用而无法返回用户态 even CTRL-C 也无能为力。这种状态通常被称为 “卡死”，此时常规的查询取消手段都会失效。
遇到这种情况，管理员可以从另一个会话使用 pg_cancel_backend () 函数尝试取消，该函数在内部发送的也是 CancelRequest 协议。如果仍然无效，可以尝试 pg_terminate_backend ()，它会发送 SIGTERM 信号而非 SIGINT，目标是直接终止 backend 进程而不是仅仅取消当前查询。只有在所有这些手段都失败后，才应考虑使用更激进的措施，例如查找并 kill 掉对应的操作系统进程，但这可能导致事务回滚不完全等副作用。
工程实践建议
从工程实践角度来看，在 psql 中使用 CTRL-C 取消查询是安全的操作，它只会取消当前语句并根据事务状态进行相应回滚。开发者应当避免在应用程序中直接向 backend 进程发送原始的 Unix 信号，而应使用 PostgreSQL 提供的 libpq 接口如 PQgetCancel 和 PQcancel 来发送规范的取消请求。这些函数封装了 CancelRequest 协议的细节，能够确保取消操作的正确性和安全性。
理解 CTRL-C 背后的协议实现，有助于在排查长时间运行查询问题时做出更准确的判断。当遇到取消请求无法生效的情况时，管理员应当意识到这可能是由于后端正在执行不可中断的代码，此时需要采用更强硬的手段或从应用层面进行优化。
title: "深入解析 psql 中 CTRL-C 信号处理机制与查询取消协议" date: "2026-03-23T15:03:33+08:00" excerpt: "深入解析 psql 中 CTRL-C 信号处理机制与查询取消协议，探讨安全的查询中断与资源释放实现细节。" category: "systems"
在日常使用 PostgreSQL 交互式客户端 psql 时，按下 CTRL-C 中断一个长时间运行的查询是最常见的操作之一。然而，这个看似简单的动作背后隐藏着一套精细的协议机制，理解它不仅能帮助开发者更好地掌握 PostgreSQL 的内部运作原理，还能在遇到查询卡死等异常情况时做出更明智的决策。
CTRL-C 的本地拦截机制
当用户在 psql 终端中按下 CTRL-C 时，psql 客户端并不会直接将 Unix 的 SIGINT 信号发送给服务器端的 backend 进程。这一设计背后有着深刻的安全考量：如果允许终端信号直接作用于远程服务器进程，可能导致连接状态不一致甚至数据库损坏。相反，psql 会在本地截获这个组合键，并触发一套名为 CancelRequest 的查询取消协议。
具体流程如下：psql 客户端会打开一条短暂的辅助连接，这条连接使用了连接初始化时服务器返回的密钥信息。通过这条专用连接，psql 向服务器发送一个取消请求消息。服务器端的 postmaster 进程接收到该请求后，会向处理当前会话的 backend 进程发送 SIGINT 信号。整个过程确保了取消请求的发起者具有合法的会话身份，从而避免了恶意中断他人查询的可能。
后端的协作式中断处理
收到 SIGINT 信号后，backend 进程并不会立即在信号处理函数中终止执行。这种设计是有意为之的，因为在信号处理上下文中执行复杂的清理操作极不安全。PostgreSQL 采用了一种协作式的中断机制：SIGINT 处理器仅设置一个全局标志位 QueryCancelPending，然后返回继续执行。正常的服务器代码在执行过程中会周期性调用 CHECK_FOR_INTERRUPTS () 宏，该宏会触发 ProcessInterrupts () 函数的执行。当检测到 QueryCancelPending 标志被设置时，ProcessInterrupts () 会抛出一个特殊的查询取消错误，这个错误会终止当前语句的执行但保留会话连接。
这种设计的优势在于它提供了一种可控的取消方式。查询被取消后，当前事务会根据其状态进行正常的回滚处理，用户会话仍然保持连接，可以继续执行新的查询。这与直接 kill 掉 backend 进程形成了鲜明对比：后者会导致事务状态不确定，可能需要重建连接甚至修复数据库。
不可中断代码与边界情况
然而，协作式中断机制并非万能。如果 backend 进程正在执行一段没有调用 CHECK_FOR_INTERRUPTS () 的代码，例如一个紧密的 C 语言循环或正在读取数据的系统调用，那么取消请求可能会被延迟处理。在极端情况下，如果后端陷入了内核态的系统调用而无法返回用户态，即使 CTRL-C 也无能为力。这种状态通常被称为 “卡死”，此时常规的查询取消手段都会失效。
遇到这种情况，管理员可以从另一个会话使用 pg_cancel_backend () 函数尝试取消，该函数在内部发送的也是 CancelRequest 协议。如果仍然无效，可以尝试 pg_terminate_backend ()，它会发送 SIGTERM 信号而非 SIGINT，目标是直接终止 backend 进程而不是仅仅取消当前查询。只有在所有这些手段都失败后，才应考虑使用更激进的措施，例如查找并 kill 掉对应的操作系统进程，但这可能导致事务回滚不完全等副作用。
工程实践建议
从工程实践角度来看，在 psql 中使用 CTRL-C 取消查询是安全的操作，它只会取消当前语句并根据事务状态进行相应回滚。开发者应当避免在应用程序中直接向 backend 进程发送原始的 Unix 信号，而应使用 PostgreSQL 提供的 libpq 接口如 PQgetCancel 和 PQcancel 来发送规范的取消请求。这些函数封装了 CancelRequest 协议的细节，能够确保取消操作的正确性和安全性。
理解 CTRL-C 背后的协议实现，有助于在排查长时间运行查询问题时做出更准确的判断。当遇到取消请求无法生效的情况时，管理员应当意识到这可能是由于后端正在执行不可中断的代码，此时需要采用更强硬的手段或从应用层面进行优化。
资料来源：PostgreSQL 官方文档关于 psql 和 libpq-cancel 的说明，以及 PostgreSQL hackers 邮件列表中关于信号处理的讨论。