AWS RDS PostgreSQL偶发死锁问题诊断及相关技术资源咨询

下次发生时的快速操作（重启前必做，耗时极短） #

• 先抓取关键锁状态：
  • 执行 SELECT * FROM pg_locks WHERE NOT granted;，直接查看哪些会话在等待锁，以及锁定对象的类型（行锁/表锁），快速定位阻塞源头
  • 执行 SELECT pid, query, state, wait_event FROM pg_stat_activity WHERE state != 'idle';，定位长时间运行的批量更新进程和proc1进程，查看它们的等待事件
  • AWS RDS用户可直接打开Performance Insights，通过可视化界面查看Top SQL的等待时间、锁等待指标，比命令行更快定位瓶颈
• 重启后必须配置的日志开关（避免下次无数据可查）：
  • 在RDS参数组中开启：log_lock_waits = on（记录锁等待事件）、deadlock_timeout = 1s（缩短死锁检测时间，更快生成日志）、log_statement = 'mod'（记录所有修改类SQL）
  • 打开RDS的Enhanced Monitoring，监控系统级的锁、CPU、IO指标

核心排查方向 #

• 锁等待链是死锁根源：批量更新是长事务+数千次单行UPDATE，会持有大量BigTable的行锁，最后才去更新table_a；而proc1是先加table_a的EXCLUSIVE表锁，再去更新BigTable。哪怕两者不更新同一行，也会形成循环等待：批量更新持有BigTable行锁→等待table_a的锁；proc1持有table_a表锁→等待BigTable的行锁，最终触发死锁
• 长事务的危害：数千次单行UPDATE的事务会持续持有锁很长时间，大幅增加与其他进程的锁冲突概率

优质参考资料 #

• PostgreSQL官方文档「锁管理」章节：重点理解表级锁与行级锁的交互逻辑、死锁检测的触发条件
• 《PostgreSQL实战》中「锁与并发控制」部分：详细讲解批量更新的优化方案、长事务锁积累的问题案例
• PostgreSQL社区技术分享：聚焦「长事务+表锁交叉导致死锁」的场景，核心优化思路是缩短事务锁持有时间

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