Parameter · Client Connection Defaults / Statement Behavior
lock_timeout
Sets the maximum allowed duration of any wait for a lock. 0 disables the timeout.
- Default:
0 - Type: integer (ms)
- Range: 0 … max (2147483647)
- Applies: Session (any user)
In plain words
When a statement needs a lock that another session holds, it waits. lock_timeout limits that wait: after the given time the statement is cancelled instead of queueing forever. It is a must-have for schema changes on busy systems.
For DBAs and operators
Applies separately to each lock acquisition attempt: table locks, row locks (SELECT … FOR UPDATE, UPDATE waiting on a row), advisory locks and other heavyweight locks. On timeout:
ERROR: canceling statement due to lock timeout
Why it matters: an ALTER TABLE waiting for its ACCESS EXCLUSIVE lock blocks every later query on that table, even plain SELECTs, because they queue behind it. A short lock_timeout plus retry turns a potential outage into a failed migration attempt:
SET lock_timeout = '3s';
ALTER TABLE orders ADD COLUMN note text; -- retry on failureIf statement_timeout is non-zero and not larger, lock_timeout is pointless. Investigate waits with pg_locks / pg_blocking_pids(pid), and log them with log_lock_waits (logs after deadlock_timeout). Setting it globally in postgresql.conf is not recommended.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
statement_timeout deadlock_timeout log_lock_waits transaction_timeout