Cookbook recipe

Diagnosing LWLock wait events

Applies to PostgreSQL 13–17 Last reviewed Nov 2025 Grounded in source
Estimated investigation4 min

Scenario

You see wait_event_type = 'LWLock' in pg_stat_activity — lightweight locks protect PostgreSQL's internal shared memory structures. Here is how to read the specific event and what to do. Diagnose it -- Current LWLock waiters grouped by…

Investigation Path

You see wait_event_type = 'LWLock' in pg_stat_activity — lightweight locks protect PostgreSQL’s internal shared memory structures. Here is how to read the specific event and what to do.

Diagnose it

-- Current LWLock waiters grouped by event:
SELECT wait_event,
       count(*) AS waiters,
       count(*) FILTER (WHERE state = 'active') AS active_waiters
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiters DESC;

Why it happens

Key LWLock events and their typical causes:

  • BufferMapping — contention on the buffer pool hash table; usually seen with many
    concurrent small-relation queries (many tables, each accessed briefly). Reduce connection count or
    consolidate workloads.
  • WALWrite / WALBufMapping — WAL buffer contention under very
    high write rates. Increase wal_buffers.
  • ProcArrayLock — contention on the process array (read during snapshot
    acquisition). Seen with very high connection counts. A connection pooler helps.
  • CLogControlLock / XactSLRULock — commit log SLRU contention.
    Correlates with high subtransaction usage.
  • LockManager — the heavyweight lock table itself is contended. Reduce the
    number of concurrent lock acquisitions.
  • RelationMappingLock — shared catalog file mapping; usually transient.

How to fix it

There is no single fix for LWLock contention — the right response depends on the specific
event. The general strategies are: reduce connection count (use a pooler), reduce concurrency
on the specific subsystem, or tune the relevant GUC (e.g., wal_buffers for
WAL-related LWLocks).

Prevent it next time

Sample pg_stat_activity for LWLock events every 15 seconds over a 10-minute
production window. Aggregate by wait_event. If any single event accounts for
more than 5% of all backend samples, it is worth a deeper investigation of the corresponding
subsystem.

Related & next steps

Career Impact

This scenario builds production judgment and operational confidence under pressure.

Open Career Dashboard →

Keep going

Related & next steps

Was this helpful?

← All cookbook recipes