Parameter · Reporting and Logging / What to Log

log_lock_failures

Logs lock failures.

Default: off
Type: bool
Applies: Session (superuser)

In plain words

When a query asks for a lock with NOWAIT and the lock is busy, it fails immediately with an error. With this setting on, PostgreSQL also logs which process held the lock, so you can find out who was in the way.

For DBAs and operators

New in PostgreSQL 18. Currently it covers only row locks requested with NOWAIT (SELECT … FOR UPDATE/SHARE NOWAIT); it does not log LOCK TABLE … NOWAIT, lock_timeout or SKIP LOCKED (verified on 18.6: those produced only the usual ERROR, or nothing). Captured on 18.6:

LOG: process 4738 could not obtain ShareLock on transaction 758 DETAIL: Process holding the lock: 4736, Wait queue: . STATEMENT: select * from t where id=7 for update nowait ERROR: could not obtain lock on row in relation "t"

Note the row lock shows up as a lock on the holder's transaction (row locks wait for the locking transaction to end). Use the holder PID with pg_stat_activity to see what it is doing, if it is still there. Superuser-settable per session, so you can enable it just for the job that uses NOWAIT. For lock waits (as opposed to failures) see log_lock_waits.

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

Related parameters

log_lock_waits lock_timeout deadlock_timeout

All Reporting and Logging parameters