调用pg_terminate_backend的查询在其所属函数运行时使用是否存在问题

核心结论 #

正常运行该查询不会出现自终止问题，调用该查询的函数所在进程不会被误杀。

逻辑说明 #

该查询的筛选条件中pid <> pg_backend_pid()的作用就是排除当前执行SQL的后端进程ID：pg_backend_pid()返回的就是当前连接对应的后端进程唯一标识，哪怕该查询是封装在函数中调用，取值也和当前函数运行所属的进程PID完全匹配，天然就不会把当前进程纳入终止列表。

需注意的异常场景 #

• 权限不足报错：只有超级用户有权限调用pg_terminate_backend()终止其他用户的后端进程，若运行函数的用户无超级用户权限，终止其他用户进程的操作会执行失败。
• 后续业务逻辑异常：若函数在执行完该终止查询后，还有依赖其他连接、未提交事务的后续逻辑，会因为其他连接都被终止出现逻辑错误，该问题属于业务逻辑设计缺陷，不是查询本身的问题。
• 跨库执行风险：如果当前连接所属数据库不是你指定的database，该查询只会终止目标库的其他连接，不会影响当前连接所属库的其他进程。

加中文注释的查询语句 #

-- 终止指定数据库下除当前连接外的所有后端进程
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() -- 排除当前连接自身的进程ID
  AND datname = 'database' -- 此处替换为实际要清理的目标数据库名称

内容的提问来源于stack exchange，提问作者SITHARA