deadlock_timeout
Controls how long a backend waits while blocked on a lock before PostgreSQL runs its deadlock-detection cycle check. It does not control lock waiting itself, only when the cycle check runs.
Defaults and ranges on this page were read from pg_settings on live PostgreSQL 18.4.
What this means
When a query is stuck waiting for a lock, Postgres does not immediately assume the worst. It waits this long first (one second by default) and only then spends the effort to check whether two sessions are deadlocked, each holding the lock the other is waiting for. Most lock waits clear on their own in well under a second, so this delay stops Postgres running that expensive check constantly. You almost never change it; the one honest reason to raise it is to hold a real deadlock open long enough to watch it in pg_stat_activity before Postgres cancels one side.
When it matters
Leave at the default for almost all workloads. Only raise it temporarily, in a non-production session, when you need a wider window to directly observe an in-progress wait-for cycle with pg_stat_activity or pg_locks before PostgreSQL auto-resolves it.
| Default | 1000 ms |
|---|---|
| Range | 1 – 2147483647 |
| Category | Locking |
SHOW deadlock_timeout;Tradeoffs
- • Too low: the deadlock-detection cycle check runs more often, adding CPU overhead even during ordinary, non-deadlocked lock contention.
- • Too high: a real deadlock takes longer to be cancelled, so both blocked sessions, and anything queued behind them, stall longer before PostgreSQL aborts one transaction.
- • The deadlock-detected (40P01) lock-visibility lab on this platform raised this to 6s for a single test run only, to create a wide, reliable window for a concurrent session to query pg_stat_activity and pg_locks and capture the real wait-for cycle before it resolved, not a production recommendation.
Workload profiles
General OLTP
Keep the 1s default.
1s is long enough to avoid false-positive cycle checks on ordinary short lock waits, while still detecting real deadlocks quickly.
Diagnosing an active deadlock
Temporarily raise it only in a non-production session while capturing pg_stat_activity/pg_locks output.
Revert immediately afterward, raising it in production delays how quickly PostgreSQL cancels a genuine deadlock.