PostgreSQL Concurrent Deadlock，點樣做 Trace 同 Deep Dive？

Question

PostgreSQL Concurrent Deadlock，點樣做 Trace 同 Deep Dive？

Cheng Ying 20

各位，我地隻 Database App 最近喺 concurrent update transactions table 嗰陣，Application log 係咁爆 Deadlock errors。

想請教下，Postgres 其實有冇好似 MSSQL 嗰種 DBCC TRACEON 嘅 Deadlock trace flags 可以 set？定係要喺 postgresql.conf 開邊啲 Logging level 先至捕捉到完整嘅 Lock Wait Graph 同 Query Details？

現時情況 / Stack：

DB: PostgreSQL

Issue: High concurrency 嗰陣爆 Deadlock (通常係 update 同一個 transaction row)

Goal: 想捉返造成死鎖嘅完整 SQL statements 同鎖住嘅 Resource ID ( Lock dependency chain )

大家平時做 Postgres Deadlock troubleshooting 會開邊啲 Parameter (例如 log_lock_waits, deadlock_timeout)？或者有冇咩 Tool / Query 睇 pg_locks 同 pg_stat_activity 可以 Share 下？Thanks！

0 則留言

由問題作者接受的回答

0 個其他答案

您的回答

Answer 1

您好，

与 SQL Server 不同，PostgreSQL 并没有提供与 DBCC TRACEON 直接对应的死锁追踪机制，但其日志功能非常完善，可以帮助您捕获完整的死锁链。针对故障排查，我建议启用 log_lock_waits = on，并将 deadlock_timeout 设置为合理的值（例如 1 秒或 2 秒），这样 PostgreSQL 会在检测到死锁之前记录锁等待情况。此外，建议启用包含 Session 和 Process Identifier 的 log_line_prefix，并配置 log_min_duration_statement，以便捕获与死锁发生时间接近的长时间运行查询。

在问题正在发生期间，结合使用 pg_locks、pg_stat_activity 和 pg_blocking_pids() 通常是识别哪些 Session 正在阻塞其他 Session 的最快方法。当发生死锁时，PostgreSQL 会自动将详细的死锁信息写入 Server Log，其中包括涉及的 Process 以及发生死锁时正在执行的 SQL Statement。如果需要进行更深入的分析，可以考虑启用 pg_stat_statements Extension，以识别频繁执行、可能导致 Lock Contention 的 SQL Statement。

在大多数环境中，真正的根本原因通常并不是死锁本身，而是事务执行顺序不一致。如果多个 Transaction 以不同的顺序更新相同的 Row，PostgreSQL 就只能终止其中一个 Transaction。建议检查 Application Logic，确保各个 Transaction 始终按照一致的顺序获取 Lock。对于反复发生的 Deadlock，这种方式通常比单纯调整 Database 参数更加有效。

希望以上说明能够对您有所帮助。如果您认为此回答有帮助，请点击 “Accept Answer”，让我知道该回答已经解决了您的问题。

Jason