Parameter · Lock Management
deadlock_timeout
Sets the time to wait on a lock before checking for deadlock.
- Default:
1s - Type: integer (ms)
- Range: 1ms … max (2147483647)
- Applies: Session (superuser)
In plain words
When a session has to wait for a lock, it might be in a deadlock: A waits for B while B waits for A. Checking for that is relatively expensive, so PostgreSQL first just waits, hoping the lock is released soon. Only after deadlock_timeout does it run the check; if it finds a cycle, one transaction gets an error and is rolled back.
The default of 1 second is fine for almost everyone. It is not a lock timeout: waiting continues after the check.
For DBAs and operators
The check walks the wait-for graph in shared memory while holding all lock partition locks, which briefly blocks every other lock operation: that is why it is delayed. On busy systems with many lock waits, a low value can cause measurable contention; raising it delays deadlock detection. The process whose timer fires and finds itself in a hard cycle aborts itself:
ERROR: deadlock detected
DETAIL: Process 4242 waits for ShareLock on transaction 771; blocked by process 4243.
Process 4243 waits for ShareLock on transaction 770; blocked by process 4242.
It also sets when log_lock_waits (off by default) reports a waiter: LOG: process 4242 still waiting for ShareLock on transaction 771 after 1000.112 ms. Turning log_lock_waits on is one of the best diagnostics for blocking problems.
- To stop waiting, use lock_timeout, not this.
- Deadlocks are application bugs: lock rows/tables in a consistent order.
pg_stat_database.deadlockscounts them. - On a hot standby, it also decides when the startup process checks for deadlocks between replay and queries holding buffer pins.
How to change it
A superuser (or a role granted SET) can change it per session with SET.
See it in context
Locking and deadlocks Isolation levels Hot standby and recovery conflicts