PostgreSQL函数因表锁冻结问题求助

问题根源 #

这行lock ;语句就是罪魁祸首！PostgreSQL的表锁机制对使用方式很敏感，哪怕是遗留的看似无害的锁语句，在特定场景下都会引发锁等待甚至死锁，直接把函数和依赖它的应用拖进无限冻结的状态。

为什么之前正常现在突然出问题？ #

之前运行没问题，近期才炸锅，通常逃不开这几个原因：

• 并发量上来了：最近系统请求变多，多个请求同时触发这个函数，大家都在抢这把锁，一旦形成等待链就彻底卡住。
• 新增了冲突事务：系统里多了其他操作同一张表的定时任务、API或者事务，和这个锁语句撞了锁。
• 锁语句本身不规范：如果这行lock ;是不完整的写法（比如本来应该是LOCK TABLE 你的表名 IN 锁模式;），PostgreSQL可能会解析成等待某个隐含资源，直接导致异常阻塞。

怎么解决？ #

1. 先把这行锁注释掉再说：既然注释后函数立刻正常，说明这就是个冗余的遗留代码——除非当初加锁是为了保证某个核心业务的原子性，但显然现在它已经变成了故障点，留着没用。
2. 如果真的需要锁机制：
   • 明确指定锁的目标表和模式，比如LOCK TABLE target_table IN SHARE MODE;或者LOCK TABLE target_table IN EXCLUSIVE MODE;，别写模糊的lock ;。
   • 把锁语句挪到真正需要原子操作的代码块前面，尽量缩短锁的持有时间，别一进函数就把整张表锁死。
   • 考虑用更细粒度的锁，比如行级锁SELECT ... FOR UPDATE，这样不会阻塞整张表的其他操作。

后续排查小技巧 #

想搞清楚具体是哪个环节在抢锁？可以查PostgreSQL的锁视图：

SELECT * FROM pg_locks WHERE NOT granted;

这个语句能列出所有正在等待锁的进程，以及对应的锁资源，帮你精准定位冲突来源。另外也可以检查下有没有长事务一直持有锁不释放。

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