pg_terminate_backend有时不生效，因目标进程可能正执行无中断检查的C函数、卡在内核态、权限不足、或pid已失效；需先查pg_stat_activity确认实时状态，再按需选用pg_cancel_backend（仅取消查询）或pg_terminate_backend（终止连接并回滚事务）。
pg_terminate_backend 为什么有时不生效？
直接执行 SELECT pg_terminate_backend(12345); 返回 true，但目标会话依然卡在 active 或 idle in transaction 状态——这不是你操作错了，而是 PostgreSQL 的终止信号被阻塞了。常见于以下情况：
- 目标进程正执行 C 函数（如自定义的无限循环
loop()），且未调用CHECK_FOR_INTERRUPTS()，无法响应中断信号 - 进程卡在内核态（比如等待磁盘 I/O、锁或网络响应），此时信号暂不被处理
- 权限不足：执行者不是超级用户，或不是该连接的拥有者（8.4+ 默认需 superuser 或同用户）
- pid 已失效：查询
pg_stat_activity时拿到的是旧 pid，实际进程已退出或被复用
如何确认目标 pid 并安全终止？
别靠猜，先查实时状态。重点过滤出真正“卡死”的会话，避免误杀健康连接：
- 查所有非空闲且运行超 5 分钟的活跃查询：
SELECT pid, usename, application_name, client_addr, state, query, now() - backend_start AS up_time FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > interval '5 minutes'; - 查长时间空闲但事务未结束的会话（最常阻塞 DDL）：
SELECT pid, usename, state, backend_start, xact_start, query FROM pg_stat_activity WHERE state = 'idle in transaction' AND now() - xact_start > interval '10 minutes'; - 若需终止整个数据库的所有非超级用户连接（如准备
DROP DATABASE）：SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'your_db' AND usename != 'postgres';
pg_cancel_backend 和 pg_terminate_backend 到底选哪个？
二者不是替代关系，是不同粒度的干预手段：
-
pg_cancel_backend(pid)：只中断当前正在执行的 SQL，连接保持，事务仍处于打开状态。适合“这个查询太慢了，重试一次就行”的场景 -
pg_terminate_backend(pid)：断开 TCP 连接，强制回滚整个事务，释放该后端进程占用的所有资源（内存、锁、临时表等）。适合连接泄漏、死锁、空闲事务长期不提交等情况 - 典型误用：对
idle in transaction会话只用pg_cancel_backend——它根本没在执行查询，所以什么也不会发生；必须用pg_terminate_backend
批量终止和脚本化操作要注意什么？
手动一条条执行 pg_terminate_backend 效率低还容易漏，但批量操作有风险：
- 生成终止语句前务必加
WHERE条件限制范围，例如：SELECT 'SELECT pg_terminate_backend(' || pid || ');' FROM pg_stat_activity WHERE state = 'idle in transaction' AND now() - xact_start > interval '30 minutes'; - 不要无条件终止所有
idle连接——很多连接池（如 PgBouncer、HikariCP）会维持长连接用于复用，杀掉反而引发重连风暴 - 生产环境建议先用
pg_cancel_backend尝试，10 秒后仍未退出再升级为pg_terminate_backend，留出缓冲窗口 - 注意：PostgreSQL 不支持事务内执行
pg_terminate_backend，也不支持在函数中嵌套调用它来“自毁”
真正卡死的进程（比如陷入 C 层死循环）可能完全无视 pg_terminate_backend，这时只能考虑操作系统级 kill（kill -9 对应后端进程 PID），但这是最后手段——它绕过 PostgreSQL 的清理逻辑，可能导致共享内存残留或 WAL 同步异常。
