执行DDL、更新或SELECT FOR UPDATE时，PostgreSQL返回canceling statement due to lock timeout。这表示语句等待某个锁超过了lock_timeout设定的时长。
超时取消的是当前语句，真正问题通常是另一个仍未结束的事务。
lock_timeout怎样生效
PostgreSQL官方说明，lock_timeout只计算等待表、索引、行或其他数据库对象锁的时间，并对每次获取锁分别计时。默认值0表示禁用；它与限制整条语句运行时间的statement_timeout不同。
当statement_timeout更短时，可能先看到语句超时而不是锁超时。
先找到被阻塞的会话
从pg_stat_activity查看当前会话的PID、事务开始时间、等待事件和脱敏后的查询。对被阻塞PID调用pg_blocking_pids(pid)，可直接取得持有冲突锁或排在前方的会话PID。
不要只凭运行时间最长就认定阻塞者。必须核对阻塞关系和事务状态。
用pg_locks确认锁对象
pg_locks会显示已持有和正在等待的锁，granted=false代表仍在等待。结合relation OID、锁模式和pg_stat_activity判断是DDL、行更新、VACUUM相关操作还是未提交事务。
行级锁通常不会直接以每一行出现在pg_locks中。等待行锁时常表现为等待另一个事务ID。
如何安全解除阻塞
优先联系业务结束或回滚长事务；确认影响后可先使用pg_cancel_backend()取消查询，必要时才用pg_terminate_backend()终止会话。终止前检查是否持有大量修改、是否来自迁移任务以及应用能否正确重试。
不要批量终止所有连接。这可能扩大回滚、连接风暴和业务中断。
超时设置与验收
更适合在会话、事务或特定角色层设置lock_timeout；官方不建议在postgresql.conf全局设置，因为会影响全部会话。可在萤光云或LightNode的测试VPS复现两个事务争锁。验收标准是阻塞链可追踪、事务及时结束、关键语句不再超时且应用具备有限重试。
FAQ
问：增大lock_timeout就能解决吗？答：只能延长等待，不能消除长事务或错误的锁顺序；过长会让请求堆积。
问：这是死锁吗？答：不一定。死锁由deadlock检测处理，lock_timeout也会取消普通的单向锁等待。
温馨提示
温馨提示：监控长事务、idle in transaction和锁等待时间。数据库迁移前评估所需锁级别，在低峰期执行，并为应用设计幂等且有上限的重试。
