deadlock_timeout

Definition PG 18 manual

This is the amount of time to wait on a lock before checking to see if there is a deadlock condition. The check for deadlock is relatively expensive, so the server doesn't run it every time it waits for a lock. We optimistically assume that deadlocks are not common in production applications and just wait on the lock for a while before checking for a deadlock. Increasing this value reduces the amount of time wasted in needless deadlock checks, but slows down reporting of real deadlock errors. If this value is specified without units, it is taken as milliseconds. The default is one second (1s), which is probably about the smallest value you would want in practice. On a heavily loaded server you might want to raise it. Ideally the setting should exceed your typical transaction time, so as to improve the odds that a lock will be released before the waiter decides to check for deadlock. Only superusers and users with the appropriate SET privilege can change this setting.

When log_lock_waits is set, this parameter also determines the amount of time to wait before a log message is issued about the lock wait. If you are trying to investigate locking delays you might want to set a shorter than normal deadlock_timeout.

How it works

Sets the time to wait on a lock before checking for deadlock. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

PostgreSQL waits this long before running the comparatively expensive deadlock detector. The same interval controls lock-wait logging when log_lock_waits is enabled, so lowering it improves diagnostics and deadlock response at the cost of more checks during ordinary contention.

Monitor and change deadlock_timeout together with log_lock_waits, lock_timeout, max_locks_per_transaction. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Reading an average shared-memory sizing value as a hard per-transaction limit.

Raising it without the multiplier from connections and prepared transactions.

Expanding lock memory instead of fixing long transactions, access order, or partition explosion.

Ignoring compatible startup lock capacity on standbys.

Workload guidance

OLAP: Partitioned queries, bulk DDL, and SERIALIZABLE reports may touch many objects; test the worst plan, not only an average transaction.

OLTP: Calibrate deadlock_timeout from lock-wait logs, objects touched, and the concurrency bound. Fix long transactions and access ordering before adding shared memory or changing detection granularity.

SMALL: Defaults are usually sufficient. If raising a startup lock-table setting, account for max_connections, prepared transactions, and standby consistency together.