PostgreSQL Wait Event Atlas
Start with the waiting sessions, not the event name
Capture who is waiting, how long, whether a transaction is open, and who blocks it. Then use the event page to connect the snapshot to PostgreSQL source and a bounded response.
official docs → pg_wait_events → source grep → executable SQLTake the first snapshot
Run this before restarting anything or cancelling a backend:
A wait-event snapshot shows where a process is sleeping now, not what consumed the elapsed query time. Repeat the snapshot and correlate it with latency, throughput, locks, and operating-system evidence before calling a wait the cause.
Continue with the wait-event triage map or open the class that matches wait_event_type.
Read by class
| Class | Read it as | First question |
|---|---|---|
| Lock | Another transaction or session owns a heavyweight lock | Who is at the head of the blocking chain? |
| LWLock | Internal shared-memory structure is contended | Is one internal resource hot across repeated samples? |
| IO | A backend is waiting for a file operation | Is storage slow, or is PostgreSQL simply doing expected work? |
| IPC | Processes are coordinating with each other | Which peer or phase has not reached the rendezvous? |
| Client | PostgreSQL is waiting on the application or network | Is the session idle, backpressured, or inside a transaction? |
| Activity | A background process is in its normal main loop | Is this expected idleness for that backend type? |
| Timeout | A deliberate timer or rate limit has not expired | Which policy intentionally inserted the delay? |
| BufferPin | A buffer cannot move while another backend pins it | Which cursor or scan is holding the pin? |
The generic extension wait-event mechanism is documented separately; extension-defined names are intentionally outside this catalogue.
Evidence contract
Every finished event page carries four different kinds of statement:
- Fact — identity, version presence, and official description.
- Analysis — the source path that reports the wait and what that path is doing.
- Advice — a workload-aware normal/trouble boundary and scenario-specific action.
- Evidence — executable SQL plus source
file:line, tied to an exact PostgreSQL release.
Use the version matrix when an event appears on one major version but not another.
A decision tree from one pg_stat_activity snapshot to the next safe action.
The reconciled PostgreSQL 13–18 wait-event inventory, including renames and type moves.
Terms used consistently across identity, analysis, advice, and evidence fields.
Heavyweight locks whose owner and blocking chain can usually be identified from SQL.
Contention on PostgreSQL’s internal shared-memory data structures.
File reads, writes, synchronization, allocation, and asynchronous I/O completion.
PostgreSQL processes waiting for peers, workers, barriers, queues, or phase changes.
PostgreSQL waiting for an application, network socket, TLS/GSS handshake, or replication client.
Background processes sleeping in their main loop until work arrives.
Deliberate sleeps, retry intervals, throttles, and rate-limiting delays.
A backend needs an exclusive buffer pin while another backend still holds one.
How PostgreSQL extensions register and report custom wait-event names, and why they are outside the core catalogue.
Configuration controls referenced by wait-event response guidance.
Signals used to decide whether a wait is expected or harmful.