1. 当PostgreSQL进程卡死时发生了什么

想象一下这样的场景：你在psql终端里执行了一个自定义函数，结果这个查询永远卡在那里。按Ctrl+C没反应，用kill命令杀不掉，甚至连pg_terminate_backend都失效了。这不是灵异事件，而是典型的PostgreSQL进程僵局。

我遇到过最棘手的案例是一个计算圆周率的C扩展函数。开发者为了追求精度，写了个无限循环逼近算法，却忘了加中断检查。结果这个函数一旦执行就会把整个后端进程拖入深渊。通过strace工具追踪，你会发现进程卡在nanosleep系统调用上，不断重复2秒的休眠：

$ strace -p 11699 nanosleep({2, 0}, 0x7fff60c0bb80) = 0 nanosleep({2, 0}, 0x7fff60c0bb80) = 0

用gstack查看调用栈更明显，堆栈卡在libc的sleep函数和自定义函数loop之间，完全没有PostgreSQL的信号处理框架参与。这就好比一辆车卡在隧道中间，既不能前进也无法倒车，连紧急制动都失效了。

2. 为什么常规终止方法都失效

PostgreSQL的信号处理机制本应是这样的：当收到SIGTERM信号时，会触发ProcessInterrupts函数，清理资源并退出。但这里有个关键前提——进程必须执行到CHECK_FOR_INTERRUPTS()宏。

在自定义C函数中，如果开发者忘记添加这个检查点（就像示例中的loop函数），就会导致：

• kill命令发送的SIGTERM信号被屏蔽
• pg_terminate_backend触发的管理员命令无法生效
• 连交互式查询的Ctrl+C请求都会被忽略

这就像给进程戴上了耳塞，无论外界怎么呼喊都听不见。更糟的是，由于PostgreSQL采用进程模型，这个僵死的进程还会占用连接槽位，影响其他会话。

3. 诊断工具三板斧

3.1 strace：系统调用显微镜

当进程无响应时，我首先会祭出strace这个神器。它能显示进程所有的系统调用：

strace -p <pid> -ff -o /tmp/pg_trace

重点关注几个关键点：

• 是否卡在I/O操作（如read/write）
• 是否有异常的锁等待（如futex）
• 信号处理状态（如rt_sigaction）

3.2 gstack：瞬间冻结调用栈

对于C扩展引起的问题，gstack能直接打印Native调用栈：

gstack <pid>

健康的PostgreSQL进程栈应该能看到Executor逻辑，而问题进程通常会卡在某个第三方库或自定义函数里。就像示例中显示的：

#2 0x00007fbbe585e145 in loop () from /path/to/loop.so

3.3 GDB：最后的救命稻草

当其他工具都无效时，GDB可以让我们手动唤醒信号处理：

gdb -p <pid> (gdb) p ProcessInterrupts()

这相当于强行给进程"戴上助听器"，让它能听到终止指令。我在生产环境用这招救回过不少卡死的分析函数。

4. 优雅终止的终极方案

4.1 为什么不能用kill -9

很多运维同学一着急就上kill -9，这简直是数据库的"安乐死"。后果包括：

1. 共享内存段泄漏
2. 子进程连锁崩溃
3. 自动重启时的WAL恢复延迟

有次我亲眼见过一个20GB的数据库因此启动花了15分钟。所以除非万不得已，千万别用这个大杀器。

4.2 GDB手动触发中断

具体操作步骤：

1. 用pg_stat_activity找到卡住的PID
2. 附加GDB调试器
3. 强制调用中断处理

gdb -p 11699 (gdb) call ProcessInterrupts() (gdb) detach

这个操作的精妙之处在于：

• 不会导致服务重启
• 会正常释放所有锁
• 保留完整的错误日志

4.3 预防性编程规范

为了避免这类问题，我在团队内制定了C扩展开发规范：

1. 所有循环必须包含CHECK_FOR_INTERRUPTS()
2. 长时间操作要分阶段执行
3. 使用PG_TRY/PG_CATCH处理异常

例如正确的循环应该像这样：

while(!done) { CHECK_FOR_INTERRUPTS(); // 业务逻辑 }

5. 深入信号处理机制

PostgreSQL的信号处理是个精密的三层架构：

1. 底层：操作系统信号捕获
2. 中间层：信号队列化处理
3. 应用层：CHECK_FOR_INTERRUPTS检查点

当自定义函数陷入死循环时，这个链条就在中间断开了。通过GDB我们实际上是绕过了正常的信号传递路径，直接激活了中断处理。

我曾经用dtrace动态跟踪过信号传递过程，发现即使信号被屏蔽，ProcessInterrupts函数本身仍然是可调用的。这就是为什么手动调用能奏效的技术根源。

6. 典型场景解决方案

6.1 第三方库卡死

有些地理信息处理的库函数会陷入长时间计算。解决方法：

1. 设置statement_timeout
2. 用PL/Proxy拆分为小任务
3. 在C函数中定期检查中断

6.2 锁等待僵局

这类情况gstack会显示ProcSleep相关调用。此时应该：

1. 检查pg_locks视图
2. 使用pg_blocking_pids定位阻塞源
3. 谨慎使用pg_terminate_backend

6.3 内存不足冻结

当OOM killer介入时，情况会更复杂。建议：

1. 监控linux内存水位线
2. 调整PostgreSQL的work_mem
3. 考虑使用cgroup限制内存

7. 监控与预警方案

完善的监控应该包含：

1. 长事务检测（age(backend_xmin)）
2. 空闲事务超时（idle_in_transaction_session_timeout）
3. 自定义扩展的白名单机制

我在实际项目中配置的预警规则示例：

CREATE EVENT TRIGGER check_long_running ON ddl_command_end EXECUTE FUNCTION check_long_queries();

这个触发器会检查执行超过1小时的查询，并通知DBA团队。