LWLock: LockManager
Waiting to read or update information about “heavyweight” locks
PostgreSQL wait event dossier
ClassLWLock
Event
LockManager
VersionsPG 13-18
Evidence3 source location(s)
Official description
Waiting to read or update information about “heavyweight” locks
| PG 13 | PG 14 | PG 15 | PG 16 | PG 17 | PG 18 |
|---|---|---|---|---|---|
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Trigger mechanism
Heavyweight lock bookkeeping is stored in shared hash tables partitioned by LockHashPartitionLock. Acquiring, granting, releasing, or inspecting many heavyweight locks can contend on the partition even when no SQL-level lock conflict exists.
Normal or trouble?
- Normal: Small bursts accompany ordinary relation and transaction lock traffic.
- Investigate: A sustained share often follows lock fan-out: very large transactions, many partitions, DDL churn, or thousands of waiting lock requests.
Diagnostic SQL
Sessions waiting on LWLock/LockManager
Current LWLock cohort
Lock and relation context for these sessions
Response
- Count pg_locks rows per PID and inspect the blocking tree.
- Identify statements touching many relations or partitions.
- Shorten transactions and reduce lock fan-out; raise max_locks_per_transaction only for genuine capacity errors.
Source evidence
- PostgreSQL 18.6 · src/backend/storage/ipc/ipci.c:117 —
LockManager - PostgreSQL 18.6 · src/backend/storage/lmgr/lwlock.c:739 —
pgstat_report_wait_start - PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:378 —
LockManager
Related controls and signals
- GUCs: [guc:max_locks_per_transaction] · [guc:max_connections]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:locks_per_backend] · [metric:blocked_sessions]
Typical incident pattern
A deployment runs DDL across thousands of partitions while application sessions acquire relation locks, creating internal lock-table contention before a clear blocker is visible.