log_lock_failures

log_lock_failures is the PostgreSQL setting that controls whether PostgreSQL logs lock failures.

Note

Fact — official short description: “Logs lock failures.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReporting and Logging / What to Log: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG18
Present in	PG18–19 Beta 3
Removed in	No
Introduction commit	`73bdcfab35ec` — Rename log_lock_failure GUC to log_lock_failures for consistency.
Commit date	2025-06-03
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG18–19 Beta 3	`off`	—	off

How it works

log_lock_failures was introduced in PostgreSQL 18 to emit a detailed message when a supported lock acquisition fails. In PostgreSQL 18 the supported scope is specifically lock failure caused by SELECT … NOWAIT; it is not a general logger for every NOWAIT-like command or every lock error.

It is a SUPERUSER-context setting. A superuser or a role with the appropriate SET privilege can change it per session, so role/database defaults and connection-pool reset behavior determine which sessions produce records.

It complements log_lock_waits: log_lock_waits reports waits that cross deadlock_timeout, whereas SELECT … NOWAIT fails immediately and can be reported here. The detailed message can expose relation, lock, and statement context and must follow the normal log access policy.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Enable it for sessions where SELECT … NOWAIT failure explains latency or retry behavior, and correlate records with application retries and lock holders. Do not expect coverage of unrelated lock errors.
OLAP	Analytical readers using SELECT … NOWAIT can use it during contention investigations; leave it off if those commands are absent because it supplies no broader wait telemetry.
Small nodes	The normal volume is low, but verify log access and retention before enabling. Pair it with log_lock_waits and deadlock diagnostics rather than treating it as a replacement.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`on`	different	`'on'`
OLAP	Unmodified	—	—
CRIT	`on`	different	`'on'`
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG18–19 Beta 3 = on (dcs); OLAP: PG18–19 Beta 3 unmodified; CRIT: PG18–19 Beta 3 = on (dcs); TINY: PG18–19 Beta 3 unmodified. Advice, pending human review — Editorial inference: the override appears intended to retain detailed evidence for SELECT … NOWAIT failures in the profiles where immediate lock-failure retries or audit diagnostics are expected to be most valuable; PostgreSQL 18 does not provide broader lock-failure coverage through this GUC.

Common pitfalls

Assuming PostgreSQL 18 logs every lock acquisition failure; currently only SELECT … NOWAIT is supported.
Using it instead of log_lock_waits even though immediate failure and a wait exceeding deadlock_timeout are different events.
Enabling it in one pooled session and assuming other sessions inherited the value.
Retaining detailed lock and statement context without appropriate log access, redaction, and retention controls.

log_checkpoints · log_autovacuum_min_duration · log_lock_waits · log_temp_files · log_replication_commands