如何调试卡在PostgreSQL事务中的Ruby进程及Sidekiq任务异常？

我来分享几个实战中踩过坑后总结的调试思路，帮你定位Sidekiq任务卡在PostgreSQL事务里的问题：

首先得确认数据库端到底发生了什么，直接连到你的PostgreSQL实例，执行这些查询：

• 查看所有活跃/闲置事务：

  SELECT pid, query, state, state_change, xact_start FROM pg_stat_activity 
  WHERE state IN ('idle in transaction', 'active');
  

  重点看xact_start（事务启动时间）和state字段，如果某个进程状态是idle in transaction且时间很久远，那就是事务挂住没提交/回滚了。
• 排查锁等待情况：

  SELECT * FROM pg_locks WHERE pid = <卡住的进程PID>;
  

  看看这个进程是不是在等待某个锁，或者它持有了其他进程需要的锁——比如同一条记录的排他锁，会导致其他更新请求阻塞。

从代码层面找线索：

• 先查Sidekiq日志：如果日志级别不够，临时调到debug模式，看任务执行的每一步细节。特别注意有没有被吞掉的异常——比如代码里写了rescue => e但没打印日志，导致事务因为异常回滚但你完全不知情。
• 检查事务边界：Rails默认会给每个Sidekiq任务套一个隐式事务，但如果手动写了ActiveRecord::Base.transaction do ... end，要确认所有代码路径都能走到commit/rollback。比如有没有分支里用return跳出了事务块，或者异常被捕获后没手动回滚？
• 警惕回调陷阱：如果你的模型有after_commit之类的回调，会不会在回调里又触发了其他Sidekiq任务？这种嵌套很容易导致循环等待或者锁冲突。

如果任务还在运行（不是单纯的idle），可以直接attach到进程看调用栈：

• 用Sidekiq自带的调试功能：给Sidekiq进程发USR1信号，比如kill -USR1 <Sidekiq进程PID>，它会自动把所有线程的调用栈打印到日志里，不用停进程，非常方便。
• 用Ruby调试工具：比如rdebug -p <进程PID> attach进去，然后输入bt查看当前执行到哪一行，能直接定位到卡住的代码位置。

能复现就好办了：

• 在测试环境用相同的记录ID手动触发任务，看是不是每次都会卡。
• 给UPDATE操作加日志，记录执行者的进程ID、任务ID，比如：

  Rails.logger.info "Updating record #{record.id} from Sidekiq job #{jid} (PID: #{Process.pid})"
  

  这样能看到是不是有多个任务同时操作同一条记录，导致锁竞争。

• 异常被静默吞噬：很多时候问题出在rescue块吞了异常但没记录，导致事务因为异常回滚，但任务看起来“卡住”了——其实是事务已经回滚，但代码没处理异常，任务一直在重试。
• 事务里塞了耗时操作：如果UPDATE之后还调用了外部API、处理大文件这类慢操作，会导致事务一直处于打开状态，PostgreSQL的锁也会一直持有，很容易引发阻塞。一定要把耗时操作移到事务外面。
• Sidekiq重试机制的副作用：如果任务卡住后，Sidekiq的超时设置没触发，旧进程还在跑，新的重试任务又进来，会导致多个事务争抢同一条记录，形成恶性循环。

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