Skip to content

LWLock: CommitTsBuffer

Waiting for I/O on a commit timestamp SLRU buffer
PostgreSQL wait event dossier
ClassLWLock EventCommitTsBuffer VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for I/O on a commit timestamp SLRU buffer

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

Trigger mechanism

pgstat_report_wait_start at src/backend/storage/lmgr/lwlock.c:739 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/storage/lmgr/lwlock.c:141. The instrumented operation is: Waiting for I/O on a commit timestamp SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as CommitTsBuffer. The generic LWLock reporter publishes the tranche name while the backend sleeps on the internal shared-memory resource.

Normal or trouble?

  • Normal: A brief sample is normal around short internal critical sections.
  • Investigate: Investigate when the same tranche affects at least 10% of active foreground sessions in three consecutive one-second samples; treat 25% or waits beyond five seconds as urgent.

Diagnostic SQL

Sessions waiting on LWLock/CommitTsBuffer
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTsBuffer'
ORDER BY query_age DESC NULLS LAST;
Current LWLock cohort
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
Lock and relation context for these sessions
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTsBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Repeat the snapshot and isolate one hot tranche.
  2. Correlate it with the protected resource and current workload phase.
  3. Reduce the specific contention source; adding concurrency can make a shared-memory hotspot worse.

Source evidence