Why this problem matters
A deadlock occurs when transactions cyclically wait for locks held by one another. PostgreSQL aborts one transaction, but user impact continues if the application mishandles the error.
How to diagnose it
Correlate pg_stat_database.deadlocks with deadlock details in logs and application transaction flow. The counter alone does not reveal which tables or statements formed the cycle.
The query shows cumulative deadlock counts per database. Log details and counter deltas are still required for root-cause analysis.
SELECT datname, deadlocks, stats_reset
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY deadlocks DESC;A safe solution approach
Make transactions access objects in a consistent order and reduce open-transaction scope. Design bounded, delayed application retries only for operations that are safe to retry.
Why continuous monitoring matters
moon helps continuously monitor changes in deadlock counters with low overhead. Slack, PagerDuty, or webhook alerts can route new recurrences to application teams.
Frequently asked questions
Does deadlocks = 0 mean there is no deadlock risk?
No, the counter only reflects events detected during its observation period. New code paths and concurrency changes can introduce future deadlocks.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.