LWLock: BufferContent
Waiting to access a data page in memory
PostgreSQL wait event dossier
ClassLWLock
Event
BufferContent
VersionsPG 13-18
Evidence3 source location(s)
Official description
Waiting to access a data page in memory
| PG 13 | PG 14 | PG 15 | PG 16 | PG 17 | PG 18 |
|---|---|---|---|---|---|
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Trigger mechanism
A backend has found the shared buffer it needs but cannot yet take that buffer descriptor’s content lock. Heap and index code acquire this lock before reading or changing the in-memory page, so many workers touching one page can serialize here.
Normal or trouble?
- Normal: Short samples are routine while concurrent readers and writers touch shared pages.
- Investigate: Repeated samples on many foreground sessions usually point to a hot heap/index page, a right-growing index, or concurrent maintenance on the same blocks.
Diagnostic SQL
Sessions waiting on LWLock/BufferContent
Current LWLock cohort
Lock and relation context for these sessions
Response
- Find the relations and statements shared by the waiters.
- Use page/index evidence to confirm a hotspot; do not infer one from the wait name alone.
- Spread hot keys, batch writes, or move maintenance away from the peak before considering capacity changes.
Source evidence
- PostgreSQL 18.6 · src/backend/storage/lmgr/lwlock.c:148 —
BufferContent - 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:373 —
BufferContent
Related controls and signals
- GUCs: [guc:shared_buffers]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:statement_latency]
Typical incident pattern
A monotonically increasing key concentrates concurrent B-tree inserts on the rightmost leaf page; BufferContent rises with insert latency.