PostgreSQL中pg_terminate_backend强制终止会话的风险与疑问

你提到可以通过以下SQL定位访问目标表的会话：

SELECT t.relname, l.locktype, pid, mode, GRANTED
FROM pg_locks l INNER JOIN pg_stat_all_tables t ON l.relation = t.relid
ORDER BY relation asc;

之后用SELECT pg_terminate_backend(xxx);终止对应PID的会话。针对你的四个问题，解答如下：

1. 该操作存在哪些潜在风险与弊端？ #

• 数据不一致或回滚异常：要是被终止的会话正处在事务中途——比如除了读表还在执行写操作——PostgreSQL会强制回滚，但极端情况下可能出现回滚不彻底，把数据卡在中间状态。
• 误杀业务会话：很容易搞错PID，把正在处理核心业务的读会话干掉，直接导致业务流程报错中断，影响用户体验。
• 数据库负载突增：一次性杀大量会话时，PostgreSQL要清理这些会话的资源，短时间内CPU、IO都会飙升，拖慢数据库整体性能。
• 锁残留问题：极少数情况，会话终止后锁资源没及时释放，还得手动排查清理，额外增加运维麻烦。

2. 将其作为常规操作频繁执行是否属于不良实践？ #

绝对属于不良实践，原因有这几点：

• 打乱连接管理节奏：频繁杀会话会让应用层反复重建连接，增加数据库的连接创建开销，长期下来会拖垮数据库整体性能。
• 掩盖核心问题：如果必须频繁杀读会话才能完成表刷新，说明你的表刷新流程和业务读流程存在架构冲突，杀会话只是治标不治本，真正该做的是优化架构——比如用分区表、增量刷新、读写分离这些方案。
• 提升运维风险：频繁操作很容易出错，还得一直盯着会话状态，消耗大量运维精力。

3. 终止会话是否始终安全？ #

当然不是，只有在确认被终止的会话没在执行关键业务、没有未完成的写事务时，终止才相对安全：

• 如果会话正在执行写事务（比如插入、更新、删除），强制终止会触发事务回滚，虽然PostgreSQL保证ACID，但大事务的回滚过程会占用大量资源，还会长期持有锁，影响其他操作。
• 要是涉及跨库或分布式事务的会话，终止后可能导致分布式事务处于悬而未决的状态，后续得人工干预才能解决。
• 哪怕是读会话，要是业务依赖这个读结果完成后续流程（比如报表生成、数据分析），终止后也会直接搞砸业务流程，影响连续性。

4. 若会话为JDBC连接，除抛出SQLException外是否会产生其他影响？ #

还有这些容易忽略的影响：

• 连接池无效连接堆积：如果应用用了连接池，被终止的JDBC连接会变成无效连接，要是连接池没开有效的连接校验（比如testOnBorrow），后续应用拿到这个无效连接时会再次报错，直到连接池把它清理掉。
• 触发应用重试风暴：如果应用有重试机制，SQLException会触发重试，短时间内大量重试会把数据库的连接请求打满，增加负载。
• 客户端状态丢失：JDBC客户端可能缓存了之前会话的临时表、自定义参数等状态，会话终止后这些状态都会丢失，要是应用没处理这种情况，后续用这个连接时可能出现奇怪的异常。

针对你的场景补充建议 #

你说在刷新表前终止读会话，且JDBC能处理SQLException，这种情况虽然能实现需求，但还是建议优化流程：比如刷新前通过业务层面通知停止读请求，或者用PostgreSQL的SET TRANSACTION READ ONLY配合隔离级别控制，或者搞读写分离，让刷新在主库执行，读请求走从库，完全不用杀会话。

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