Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

PostgreSQL Wait Event Atlas

What the backend is waiting for, where the wait begins, and what an operator should do next.
Operator entry point

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.

13–18PostgreSQL versions
327versioned matrix identities
8operator-facing classes
2languages, paired page-for-page
Fact chainofficial docs → pg_wait_events → source grep → executable SQL

Take the first snapshot

Run this before restarting anything or cancelling a backend:

Waiting sessions right now 
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 IS NOT NULL
ORDER BY query_age DESC NULLS LAST;
Important

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:

  1. Fact — identity, version presence, and official description.
  2. Analysis — the source path that reports the wait and what that path is doing.
  3. Advice — a workload-aware normal/trouble boundary and scenario-specific action.
  4. 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.

1 - Wait-event triage map

A decision tree from one pg_stat_activity snapshot to the next safe action.

The map is deliberately conservative: preserve evidence first, separate expected idleness from stalled work, and only then choose a class-specific drill-down.

flowchart TD
  A[Capture pg_stat_activity] --> B{wait_event is null?}
  B -- yes --> C[The backend is on CPU or between instrumentation points]
  B -- no --> D{Activity or Client?}
  D -- yes --> E{Idle state or expected background loop?}
  E -- yes --> F[Usually normal; check open transactions and connection volume]
  E -- no --> G[Check client backpressure, network, and application ownership]
  D -- no --> H{Lock or BufferPin?}
  H -- yes --> I[Build the blocking chain and identify the root holder]
  H -- no --> J{IO?}
  J -- yes --> K[Correlate with pg_stat_io, filesystem latency, and workload phase]
  J -- no --> L{LWLock?}
  L -- yes --> M[Repeat snapshots; identify one hot internal resource]
  L -- no --> N[Inspect IPC peer or Timeout policy]
  I --> O[Choose the least disruptive bounded action]
  K --> O
  M --> O
  N --> O

Minimum evidence bundle

  • Two or more snapshots with timestamps.
  • pid, backend_type, state, query age, transaction age, event type and name.
  • pg_blocking_pids(pid) for every waiting backend.
  • The exact PostgreSQL major/minor version.
  • A workload marker: deploy, batch, checkpoint, vacuum, backup, DDL, or failover.
Warning

Do not terminate a backend merely because its wait is frequent. Activity, many Client, and timer waits can dominate a healthy cluster by design.

2 - Version matrix

The reconciled PostgreSQL 13–18 wait-event inventory, including renames and type moves.

The matrix reconciles two factual paths: PostgreSQL 13–16 monitoring tables and live pg_wait_events rows from PostgreSQL 17–18 Docker instances.

Version Extraction authority Rows
13 Official monitoring documentation 222
14 Official monitoring documentation 231
15 Official monitoring documentation 238
16 Official monitoring documentation 246
17 Docker postgres:17, queried from pg_wait_events 265
18 Docker postgres:18, queried from pg_wait_events 274

The union contains 327 exact (type, name) identities. Forty-five historical identities resolve into 282 semantic dossiers: 281 core event entries plus one Extension mechanism placeholder. The mappings cover two type moves in PG14, two reviewed Parallel Hash renames in PG16, and PostgreSQL’s PG17 wait-name spelling normalization.

Downloads

The CSV deliberately preserves old and new names as separate rows and provides a canonical column. Event pages consolidate those rows through explicit aliases without erasing their real version ranges.

Rename policy

Names are linked only when the evidence is deterministic: the adjacent replacement is alphanumerically identical after case normalization, or the source/documentation establishes the reviewed rename. Similar descriptions alone are not enough; removals such as PgStatMain remain historical events rather than speculative aliases.

Complete identity matrix

Type Event identity 13 14 15 16 17 18 Canonical / change
Activity ArchiverMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity AutoVacuumMain ✓ ✓ ✓ ✓ Activity/AutovacuumMain · spelling
Activity AutovacuumMain ✓ ✓ —
Activity BgWriterHibernate ✓ ✓ ✓ ✓ Activity/BgwriterHibernate · spelling
Activity BgWriterMain ✓ ✓ ✓ ✓ Activity/BgwriterMain · spelling
Activity BgwriterHibernate ✓ ✓ —
Activity BgwriterMain ✓ ✓ —
Activity CheckpointerMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity CheckpointerShutdown ✓ —
Activity IoWorkerMain ✓ —
Activity LogicalApplyMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity LogicalLauncherMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity LogicalParallelApplyMain ✓ ✓ ✓ —
Activity PgStatMain ✓ ✓ —
Activity RecoveryWalStream ✓ ✓ ✓ ✓ ✓ ✓ —
Activity ReplicationSlotsyncMain ✓ ✓ —
Activity ReplicationSlotsyncShutdown ✓ ✓ —
Activity SysLoggerMain ✓ ✓ ✓ ✓ Activity/SysloggerMain · spelling
Activity SysloggerMain ✓ ✓ —
Activity WalReceiverMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity WalSenderMain ✓ ✓ ✓ ✓ ✓ ✓ —
Activity WalSummarizerWal ✓ ✓ —
Activity WalWriterMain ✓ ✓ ✓ ✓ ✓ ✓ —
BufferPin BufferPin ✓ ✓ ✓ ✓ ✓ ✓ —
Client ClientRead ✓ ✓ ✓ ✓ ✓ ✓ —
Client ClientWrite ✓ ✓ ✓ ✓ ✓ ✓ —
Client GSSOpenServer ✓ ✓ ✓ ✓ Client/GssOpenServer · spelling
Client GssOpenServer ✓ ✓ —
Client LibPQWalReceiverConnect ✓ ✓ ✓ ✓ Client/LibpqwalreceiverConnect · spelling
Client LibPQWalReceiverReceive ✓ ✓ ✓ ✓ Client/LibpqwalreceiverReceive · spelling
Client LibpqwalreceiverConnect ✓ ✓ —
Client LibpqwalreceiverReceive ✓ ✓ —
Client SSLOpenServer ✓ ✓ ✓ ✓ Client/SslOpenServer · spelling
Client SslOpenServer ✓ ✓ —
Client WaitForStandbyConfirmation ✓ ✓ —
Client WalReceiverWaitStart ✓ IPC/WalReceiverWaitStart · type_move
Client WalSenderWaitForWAL ✓ ✓ ✓ ✓ Client/WalSenderWaitForWal · spelling
Client WalSenderWaitForWal ✓ ✓ —
Client WalSenderWriteData ✓ ✓ ✓ ✓ ✓ ✓ —
Extension Extension ✓ ✓ ✓ ✓ ✓ ✓ —
IO AioIoCompletion ✓ —
IO AioIoUringExecution ✓ —
IO AioIoUringSubmit ✓ —
IO BaseBackupRead ✓ ✓ ✓ IO/BasebackupRead · spelling
IO BaseBackupSync ✓ ✓ IO/BasebackupSync · spelling
IO BaseBackupWrite ✓ ✓ IO/BasebackupWrite · spelling
IO BasebackupRead ✓ ✓ —
IO BasebackupSync ✓ ✓ —
IO BasebackupWrite ✓ ✓ —
IO BufFileRead ✓ ✓ ✓ ✓ IO/BuffileRead · spelling
IO BufFileTruncate ✓ ✓ ✓ IO/BuffileTruncate · spelling
IO BufFileWrite ✓ ✓ ✓ ✓ IO/BuffileWrite · spelling
IO BuffileRead ✓ ✓ —
IO BuffileTruncate ✓ ✓ —
IO BuffileWrite ✓ ✓ —
IO ControlFileRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO ControlFileSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO ControlFileSyncUpdate ✓ ✓ ✓ ✓ ✓ ✓ —
IO ControlFileWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO ControlFileWriteUpdate ✓ ✓ ✓ ✓ ✓ ✓ —
IO CopyFileCopy ✓ —
IO CopyFileRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO CopyFileWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO DSMAllocate ✓ IO/DsmAllocate · spelling
IO DSMFillZeroWrite ✓ ✓ ✓ ✓ IO/DsmFillZeroWrite · spelling
IO DataFileExtend ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileFlush ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileImmediateSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFilePrefetch ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileTruncate ✓ ✓ ✓ ✓ ✓ ✓ —
IO DataFileWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO DsmAllocate ✓ ✓ —
IO DsmFillZeroWrite ✓ ✓ —
IO LockFileAddToDataDirRead ✓ ✓ ✓ ✓ IO/LockFileAddtodatadirRead · spelling
IO LockFileAddToDataDirSync ✓ ✓ ✓ ✓ IO/LockFileAddtodatadirSync · spelling
IO LockFileAddToDataDirWrite ✓ ✓ ✓ ✓ IO/LockFileAddtodatadirWrite · spelling
IO LockFileAddtodatadirRead ✓ ✓ —
IO LockFileAddtodatadirSync ✓ ✓ —
IO LockFileAddtodatadirWrite ✓ ✓ —
IO LockFileCreateRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO LockFileCreateSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO LockFileCreateWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO LockFileReCheckDataDirRead ✓ ✓ ✓ ✓ IO/LockFileRecheckdatadirRead · spelling
IO LockFileRecheckdatadirRead ✓ ✓ —
IO LogicalChangesRead ✓ —
IO LogicalChangesWrite ✓ —
IO LogicalRewriteCheckpointSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalRewriteMappingSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalRewriteMappingWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalRewriteSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalRewriteTruncate ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalRewriteWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO LogicalSubxactRead ✓ —
IO LogicalSubxactWrite ✓ —
IO RelationMapRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO RelationMapReplace ✓ ✓ ✓ —
IO RelationMapSync ✓ ✓ ✓ —
IO RelationMapWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReorderBufferRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReorderBufferWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReorderLogicalMappingRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReplicationSlotRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReplicationSlotRestoreSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReplicationSlotSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO ReplicationSlotWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO SLRUFlushSync ✓ ✓ ✓ ✓ IO/SlruFlushSync · spelling
IO SLRURead ✓ ✓ ✓ ✓ IO/SlruRead · spelling
IO SLRUSync ✓ ✓ ✓ ✓ IO/SlruSync · spelling
IO SLRUWrite ✓ ✓ ✓ ✓ IO/SlruWrite · spelling
IO SlruFlushSync ✓ ✓ —
IO SlruRead ✓ ✓ —
IO SlruSync ✓ ✓ —
IO SlruWrite ✓ ✓ —
IO SnapbuildRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO SnapbuildSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO SnapbuildWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO TimelineHistoryFileSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO TimelineHistoryFileWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO TimelineHistoryRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO TimelineHistorySync ✓ ✓ ✓ ✓ ✓ ✓ —
IO TimelineHistoryWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO TwophaseFileRead ✓ ✓ ✓ ✓ ✓ ✓ —
IO TwophaseFileSync ✓ ✓ ✓ ✓ ✓ ✓ —
IO TwophaseFileWrite ✓ ✓ ✓ ✓ ✓ ✓ —
IO VersionFileSync ✓ ✓ ✓ ✓ —
IO VersionFileWrite ✓ ✓ ✓ ✓ —
IO WALBootstrapSync ✓ ✓ ✓ ✓ IO/WalBootstrapSync · spelling
IO WALBootstrapWrite ✓ ✓ ✓ ✓ IO/WalBootstrapWrite · spelling
IO WALCopyRead ✓ ✓ ✓ ✓ IO/WalCopyRead · spelling
IO WALCopySync ✓ ✓ ✓ ✓ IO/WalCopySync · spelling
IO WALCopyWrite ✓ ✓ ✓ ✓ IO/WalCopyWrite · spelling
IO WALInitSync ✓ ✓ ✓ ✓ IO/WalInitSync · spelling
IO WALInitWrite ✓ ✓ ✓ ✓ IO/WalInitWrite · spelling
IO WALRead ✓ ✓ ✓ ✓ IO/WalRead · spelling
IO WALSenderTimelineHistoryRead ✓ ✓ ✓ ✓ IO/WalsenderTimelineHistoryRead · spelling
IO WALSync ✓ ✓ ✓ ✓ IO/WalSync · spelling
IO WALSyncMethodAssign ✓ ✓ ✓ ✓ IO/WalSyncMethodAssign · spelling
IO WALWrite ✓ ✓ ✓ ✓ IO/WalWrite · spelling
IO WalBootstrapSync ✓ ✓ —
IO WalBootstrapWrite ✓ ✓ —
IO WalCopyRead ✓ ✓ —
IO WalCopySync ✓ ✓ —
IO WalCopyWrite ✓ ✓ —
IO WalInitSync ✓ ✓ —
IO WalInitWrite ✓ ✓ —
IO WalRead ✓ ✓ —
IO WalSummaryRead ✓ ✓ —
IO WalSummaryWrite ✓ ✓ —
IO WalSync ✓ ✓ —
IO WalSyncMethodAssign ✓ ✓ —
IO WalWrite ✓ ✓ —
IO WalsenderTimelineHistoryRead ✓ ✓ —
IPC AppendReady ✓ ✓ ✓ ✓ ✓ —
IPC ArchiveCleanupCommand ✓ ✓ ✓ ✓ —
IPC ArchiveCommand ✓ ✓ ✓ ✓ —
IPC BackendTermination ✓ ✓ ✓ ✓ ✓ —
IPC BackupWaitWalArchive ✓ ✓ ✓ ✓ ✓ ✓ —
IPC BgWorkerShutdown ✓ ✓ ✓ ✓ IPC/BgworkerShutdown · spelling
IPC BgWorkerStartup ✓ ✓ ✓ ✓ IPC/BgworkerStartup · spelling
IPC BgworkerShutdown ✓ ✓ —
IPC BgworkerStartup ✓ ✓ —
IPC BtreePage ✓ ✓ ✓ ✓ ✓ ✓ —
IPC BufferIO ✓ ✓ ✓ IPC/BufferIo · spelling
IPC BufferIo ✓ ✓ —
IPC CheckpointDelayComplete ✓ ✓ —
IPC CheckpointDelayStart ✓ ✓ —
IPC CheckpointDone ✓ ✓ ✓ ✓ ✓ ✓ —
IPC CheckpointStart ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ExecuteGather ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBatchAllocate ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBatchElect ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBatchLoad ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBuildAllocate ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBuildElect ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBuildHashInner ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashBuildHashOuter ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBatchesAllocate ✓ ✓ ✓ IPC/HashGrowBatchesReallocate · rename
IPC HashGrowBatchesDecide ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBatchesElect ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBatchesFinish ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBatchesReallocate ✓ ✓ ✓ —
IPC HashGrowBatchesRepartition ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBucketsAllocate ✓ ✓ ✓ IPC/HashGrowBucketsReallocate · rename
IPC HashGrowBucketsElect ✓ ✓ ✓ ✓ ✓ ✓ —
IPC HashGrowBucketsReallocate ✓ ✓ ✓ —
IPC HashGrowBucketsReinsert ✓ ✓ ✓ ✓ ✓ ✓ —
IPC LogicalApplySendData ✓ ✓ ✓ —
IPC LogicalParallelApplyStateChange ✓ ✓ ✓ —
IPC LogicalSyncData ✓ ✓ ✓ ✓ ✓ ✓ —
IPC LogicalSyncStateChange ✓ ✓ ✓ ✓ ✓ ✓ —
IPC MessageQueueInternal ✓ ✓ ✓ ✓ ✓ ✓ —
IPC MessageQueuePutMessage ✓ ✓ ✓ ✓ ✓ ✓ —
IPC MessageQueueReceive ✓ ✓ ✓ ✓ ✓ ✓ —
IPC MessageQueueSend ✓ ✓ ✓ ✓ ✓ ✓ —
IPC MultixactCreation ✓ ✓ —
IPC ParallelBitmapScan ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ParallelCreateIndexScan ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ParallelFinish ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ProcArrayGroupUpdate ✓ ✓ ✓ ✓ IPC/ProcarrayGroupUpdate · spelling
IPC ProcSignalBarrier ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ProcarrayGroupUpdate ✓ ✓ —
IPC Promote ✓ ✓ ✓ ✓ ✓ ✓ —
IPC RecoveryConflictSnapshot ✓ ✓ ✓ ✓ ✓ ✓ —
IPC RecoveryConflictTablespace ✓ ✓ ✓ ✓ ✓ ✓ —
IPC RecoveryEndCommand ✓ ✓ ✓ ✓ —
IPC RecoveryPause ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ReplicationOriginDrop ✓ ✓ ✓ ✓ ✓ ✓ —
IPC ReplicationSlotDrop ✓ ✓ ✓ ✓ ✓ ✓ —
IPC RestoreCommand ✓ ✓ ✓ ✓ —
IPC SafeSnapshot ✓ ✓ ✓ ✓ ✓ ✓ —
IPC SyncRep ✓ ✓ ✓ ✓ ✓ ✓ —
IPC WalReceiverExit ✓ ✓ ✓ ✓ ✓ —
IPC WalReceiverUpstreamCatchup ✓ ✓ —
IPC WalReceiverWaitStart ✓ ✓ ✓ ✓ ✓ —
IPC WalSummaryReady ✓ ✓ —
IPC XactGroupUpdate ✓ ✓ ✓ ✓ ✓ ✓ —
Lock advisory ✓ ✓ ✓ ✓ ✓ ✓ —
Lock applytransaction ✓ ✓ ✓ —
Lock extend ✓ ✓ ✓ ✓ ✓ ✓ —
Lock frozenid ✓ ✓ ✓ ✓ ✓ ✓ —
Lock object ✓ ✓ ✓ ✓ ✓ ✓ —
Lock page ✓ ✓ ✓ ✓ ✓ ✓ —
Lock relation ✓ ✓ ✓ ✓ ✓ ✓ —
Lock spectoken ✓ ✓ ✓ ✓ ✓ ✓ —
Lock transactionid ✓ ✓ ✓ ✓ ✓ ✓ —
Lock tuple ✓ ✓ ✓ ✓ ✓ ✓ —
Lock userlock ✓ ✓ ✓ ✓ ✓ ✓ —
Lock virtualxid ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock AddinShmemInit ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock AioUringCompletion ✓ —
LWLock AioWorkerSubmissionQueue ✓ —
LWLock AutoFile ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock Autovacuum ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock AutovacuumSchedule ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock BackgroundWorker ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock BtreeVacuum ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock BufferContent ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock BufferIO ✓ IPC/BufferIo · type_move
LWLock BufferMapping ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock Checkpoint ✓ —
LWLock CheckpointerComm ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock CommitTs ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock CommitTsBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock CommitTsSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ControlFile ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock DSMRegistry ✓ ✓ —
LWLock DSMRegistryDSA ✓ ✓ —
LWLock DSMRegistryHash ✓ ✓ —
LWLock DynamicSharedMemoryControl ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock InjectionPoint ✓ ✓ —
LWLock LockFastPath ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock LockManager ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock LogicalRepLauncherDSA ✓ ✓ ✓ —
LWLock LogicalRepLauncherHash ✓ ✓ ✓ —
LWLock LogicalRepWorker ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactGen ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactMemberBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactMemberSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactOffsetBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactOffsetSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock MultiXactTruncation ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock NotifyBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock NotifyQueue ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock NotifyQueueTail ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock NotifySLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock OidGen ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock OldSnapshotTimeMap ✓ ✓ ✓ ✓ —
LWLock ParallelAppend ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ParallelBtreeScan ✓ —
LWLock ParallelHashJoin ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ParallelQueryDSA ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ParallelVacuumDSA ✓ ✓ —
LWLock PerSessionDSA ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock PerSessionRecordType ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock PerSessionRecordTypmod ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock PerXactPredicateList ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock PgStatsDSA ✓ ✓ ✓ ✓ —
LWLock PgStatsData ✓ ✓ ✓ ✓ —
LWLock PgStatsHash ✓ ✓ ✓ ✓ —
LWLock PredicateLockManager ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ProcArray ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock RelCacheInit ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock RelationMapping ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ReplicationOrigin ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ReplicationOriginState ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ReplicationSlotAllocation ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ReplicationSlotControl ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ReplicationSlotIO ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SInvalRead ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SInvalWrite ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SerialBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SerialControl ✓ ✓ —
LWLock SerialSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SerializableFinishedList ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SerializablePredicateList ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SerializableXactHash ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SharedTidBitmap ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SharedTupleStore ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock ShmemIndex ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SubtransBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SubtransSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SyncRep ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock SyncScan ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock TablespaceCreate ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock TwoPhaseState ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock WALBufMapping ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock WALInsert ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock WALSummarizer ✓ ✓ —
LWLock WALWrite ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock WaitEventCustom ✓ ✓ —
LWLock WrapLimitsVacuum ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock XactBuffer ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock XactSLRU ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock XactTruncation ✓ ✓ ✓ ✓ ✓ ✓ —
LWLock XidGen ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout BaseBackupThrottle ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout CheckpointWriteDelay ✓ ✓ ✓ ✓ ✓ —
Timeout PgSleep ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout RecoveryApplyDelay ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout RecoveryRetrieveRetryInterval ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout RegisterSyncRequest ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout SpinDelay ✓ ✓ ✓ —
Timeout VacuumDelay ✓ ✓ ✓ ✓ ✓ ✓ —
Timeout VacuumTruncate ✓ ✓ ✓ ✓ —
Timeout WalSummarizerError ✓ ✓ —

3 - Operator glossary

Terms used consistently across identity, analysis, advice, and evidence fields.
Term Meaning in this atlas
Active foreground session A client-facing backend with state = 'active'; background main loops are excluded from contention percentages.
Snapshot share The fraction of sampled active foreground sessions on one event. It is a triage signal, not elapsed-time attribution.
Wait identity Exact (wait_event_type, wait_event) spelling observed in a release. Renames remain separate matrix rows.
Canonical event One semantic dossier that can consolidate explicitly verified historical spellings or type moves.
Trigger The source path that passes a wait-event identifier to PostgreSQL’s wait reporting machinery.
Catalog definition A source row that defines the public name/description. It is not automatically proof of a live trigger.
Dormant event A catalog identity with verified negative source evidence: no live core reporter in the audited patch release.
Heavyweight lock SQL-visible lock-manager object, normally diagnosable through pg_locks and pg_blocking_pids().
LWLock / tranche Short internal lock protecting shared-memory state; the tranche supplies the displayed event name.
SLRU Small shared cache and on-disk segment set for transaction-related metadata such as pg_xact and multixact.
Buffer pin A backend’s temporary claim that a shared buffer page must remain present and structurally stable.
Source release Exact audited tag, such as REL_18_6; line numbers are never attached to a drifting stable branch.

Advice thresholds in this site are operational defaults. PostgreSQL does not promise that “10%” or “five seconds” is universally bad; use the cluster’s own baseline and service objectives.

4 - Lock waits

Heavyweight locks whose owner and blocking chain can usually be identified from SQL.

Lock is the most directly actionable class: a backend asked the lock manager for a heavyweight lock and an incompatible holder has not released it. Unlike LWLocks, these waits usually have rows in pg_locks and a useful result from pg_blocking_pids().

Read the blocking graph, not the victim count

Twenty waiters can all be symptoms of one idle transaction. Start at the head of the graph, then decide whether the holder is doing useful work, abandoned, or participating in an expected DDL/deploy window.

  • Normal: sub-second lock handoff during ordinary writes or planned DDL.
  • Watch: any user-facing waiter persists beyond its latency objective, or at least 10% of active sessions wait on the same root blocker.
  • Urgent: the root holder is idle in transaction, the chain keeps growing, critical DDL blocks traffic, or deadlocks begin to rise.

Events to recognize

Event Usually means
relation Table/index-level lock conflict, often DDL versus DML
transactionid Waiting for another transaction’s outcome, commonly row updates
tuple Competing tuple locks or a long row-lock queue
extend Sessions serialize while extending one relation
virtualxid DDL waits for transactions that might still use an object
advisory Application-defined advisory-lock coordination

Blocker query 

SELECT w.pid AS waiting_pid, b.pid AS blocking_pid,
       w.wait_event, now() - w.query_start AS waiting_for,
       now() - b.xact_start AS blocker_xact_age,
       b.state AS blocker_state,
       left(w.query, 100) AS waiting_query,
       left(b.query, 100) AS blocking_query
FROM pg_stat_activity AS w
CROSS JOIN LATERAL unnest(pg_blocking_pids(w.pid)) AS x(pid)
JOIN pg_stat_activity AS b ON b.pid = x.pid
ORDER BY waiting_for DESC;

Common misreads

  • A session listed as a blocker is not automatically safe to terminate; it may be the only writer preserving an invariant.
  • transactionid does not mean transaction-ID exhaustion.
  • relation does not identify the relation by itself; join pg_locks.relation to pg_class.
  • Increasing lock_timeout changes how long victims wait; it does not remove the blocker.

4.1 - Lock: advisory

Waiting to acquire an advisory user lock
PostgreSQL wait event dossier
ClassLock Eventadvisory VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire an advisory user lock

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:428. The instrumented operation is: Waiting to acquire an advisory user lock. The lock manager could not grant the advisory heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/advisory 
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 = 'Lock'
  AND wait_event = 'advisory'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'advisory'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.2 - Lock: applytransaction

Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber
PostgreSQL wait event dossier
ClassLock Eventapplytransaction VersionsPG 16-18 Evidence3 source location(s)

Official description

Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:429. The instrumented operation is: Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber. The lock manager could not grant the applytransaction heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/applytransaction 
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 = 'Lock'
  AND wait_event = 'applytransaction'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'applytransaction'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.3 - Lock: extend

Waiting to extend a relation
PostgreSQL wait event dossier
ClassLock Eventextend VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to extend a relation

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:419. The instrumented operation is: Waiting to extend a relation. The lock manager could not grant the extend heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/extend 
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 = 'Lock'
  AND wait_event = 'extend'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'extend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.4 - Lock: frozenid

Waiting to update pg_database.datfrozenxid and pg_database.datminmxid
PostgreSQL wait event dossier
ClassLock Eventfrozenid VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to update pg_database.datfrozenxid and pg_database.datminmxid

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:420. The instrumented operation is: Waiting to update pg_database.datfrozenxid and pg_database.datminmxid. The lock manager could not grant the frozenid heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/frozenid 
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 = 'Lock'
  AND wait_event = 'frozenid'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'frozenid'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.5 - Lock: object

Waiting to acquire a lock on a non-relation database object
PostgreSQL wait event dossier
ClassLock Eventobject VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a lock on a non-relation database object

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:426. The instrumented operation is: Waiting to acquire a lock on a non-relation database object. The lock manager could not grant the object heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/object 
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 = 'Lock'
  AND wait_event = 'object'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'object'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.6 - Lock: page

Waiting to acquire a lock on a page of a relation
PostgreSQL wait event dossier
ClassLock Eventpage VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to acquire a lock on a page of a relation

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:421. The instrumented operation is: Waiting to acquire a lock on a page of a relation. The lock manager could not grant the page heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/page 
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 = 'Lock'
  AND wait_event = 'page'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'page'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.7 - Lock: relation

Waiting to acquire a lock on a relation
PostgreSQL wait event dossier
ClassLock Eventrelation VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a lock on a relation

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:418. The instrumented operation is: Waiting to acquire a lock on a relation. The lock manager could not grant the relation heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/relation 
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 = 'Lock'
  AND wait_event = 'relation'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'relation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.8 - Lock: spectoken

Waiting to acquire a speculative insertion lock
PostgreSQL wait event dossier
ClassLock Eventspectoken VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a speculative insertion lock

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:425. The instrumented operation is: Waiting to acquire a speculative insertion lock. The lock manager could not grant the spectoken heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/spectoken 
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 = 'Lock'
  AND wait_event = 'spectoken'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'spectoken'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.9 - Lock: transactionid

Waiting for a transaction to finish
PostgreSQL wait event dossier
ClassLock Eventtransactionid VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for a transaction to finish

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:423. The instrumented operation is: Waiting for a transaction to finish. The lock manager could not grant the transactionid heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/transactionid 
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 = 'Lock'
  AND wait_event = 'transactionid'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'transactionid'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.10 - Lock: tuple

Waiting to acquire a lock on a tuple
PostgreSQL wait event dossier
ClassLock Eventtuple VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a lock on a tuple

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:422. The instrumented operation is: Waiting to acquire a lock on a tuple. The lock manager could not grant the tuple heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/tuple 
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 = 'Lock'
  AND wait_event = 'tuple'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'tuple'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.11 - Lock: userlock

Waiting to acquire a user lock
PostgreSQL wait event dossier
ClassLock Eventuserlock VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a user lock

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:427. The instrumented operation is: Waiting to acquire a user lock. The lock manager could not grant the userlock heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/userlock 
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 = 'Lock'
  AND wait_event = 'userlock'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'userlock'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

4.12 - Lock: virtualxid

Waiting to acquire a virtual transaction ID lock
PostgreSQL wait event dossier
ClassLock Eventvirtualxid VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to acquire a virtual transaction ID lock

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

Trigger mechanism

PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:424. The instrumented operation is: Waiting to acquire a virtual transaction ID lock. The lock manager could not grant the virtualxid heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.

Normal or trouble?

  • Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
  • Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.

Diagnostic SQL

Sessions waiting on Lock/virtualxid 
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 = 'Lock'
  AND wait_event = 'virtualxid'
ORDER BY query_age DESC NULLS LAST;
Current Lock 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 = 'Lock'
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 = 'Lock'
  AND a.wait_event = 'virtualxid'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Build the pg_blocking_pids graph to its root.
  2. Inspect the root holder’s state, transaction age, and business purpose.
  3. Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.

Source evidence

Related controls and signals

5 - LWLock waits

Contention on PostgreSQL’s internal shared-memory data structures.

LWLock means a backend could not immediately acquire a lightweight lock that protects an internal shared-memory structure. It does not identify a SQL row or table lock, and pg_locks usually cannot name its owner.

Operator rulerepeat samples → isolate one hot tranche → correlate with workload

How to read this class

A single sample is ordinary scheduler noise. Treat the event as contention only when the same LWLock name recurs across consecutive samples and affects foreground sessions whose latency has increased.

  • Normal: brief appearances during WAL generation, snapshot acquisition, buffer lookup, vacuum, or checkpoint work.
  • Watch: the same event occupies at least 10% of active foreground backends in three consecutive 1-second snapshots.
  • Urgent: at least 25% of active foreground backends pile onto one event, waits persist beyond 5 seconds, or throughput collapses at the same time.

The percentages are operational triage thresholds, not PostgreSQL guarantees. Compare with the cluster’s own baseline and exclude background processes whose main loop is expected to wait.

Ten events worth recognizing

Event Protected resource Typical story
BufferContent Contents of one shared buffer Many sessions touch the same hot page
BufferMapping Buffer-table mapping partitions Working-set churn or broad concurrent scans
LockManager Heavyweight lock manager state Large lock fan-out, DDL, or lock storms
ProcArray Shared process/transaction array Snapshot and transaction-ID pressure
WALBufMapping WAL buffer page mapping WAL buffers turn over under write pressure
WALInsert WAL insertion state Many writers serialize while inserting WAL
WALWrite WAL buffer write coordination WAL flush/write path cannot keep up
XactSLRU Transaction-status SLRU pg_xact cache churn or old visibility checks
MultiXactMemberSLRU Multixact-member SLRU Heavy row-locking and multixact churn
SyncRep Synchronous replication wait queues Commit acknowledgements and sender state contend

Common misreads

  1. “LWLock means a leaked lock.” No. It is a short internal critical section; sustained recurrence is the signal.
  2. “The query shown owns the lock.” pg_stat_activity.query belongs to the waiter. The holder can be another backend inside a different source path.
  3. “More CPU fixes it.” Extra concurrency can intensify a shared-memory hotspot. First identify the protected resource and workload shape.
  4. “pg_locks will reveal the blocker.” It covers heavyweight and predicate locks, not general LWLock ownership.

Start with BufferContent for a page-level hotspot and WALInsert for a write-heavy cluster.

5.1 - LWLock: AddinShmemInit

Waiting to manage an extension’s space allocation in shared memory
PostgreSQL wait event dossier
ClassLWLock EventAddinShmemInit VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to manage an extension’s space allocation in shared memory

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/utils/activity/wait_event_names.txt:328. The instrumented operation is: Waiting to manage an extension’s space allocation in shared memory. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as AddinShmemInit. 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/AddinShmemInit 
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 = 'AddinShmemInit'
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 = 'AddinShmemInit'
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

Related controls and signals

5.2 - LWLock: AioUringCompletion

Waiting for another process to complete IO via io_uring
PostgreSQL wait event dossier
ClassLWLock EventAioUringCompletion VersionsPG 18 Evidence3 source location(s)

Official description

Waiting for another process to complete IO via io_uring

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:180. The instrumented operation is: Waiting for another process to complete IO via io_uring. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as AioUringCompletion. 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/AioUringCompletion 
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 = 'AioUringCompletion'
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 = 'AioUringCompletion'
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

Related controls and signals

5.3 - LWLock: AioWorkerSubmissionQueue

Waiting to access AIO worker submission queue
PostgreSQL wait event dossier
ClassLWLock EventAioWorkerSubmissionQueue VersionsPG 18 Evidence3 source location(s)

Official description

Waiting to access AIO worker submission queue

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/aio/method_worker.c:253. The instrumented operation is: Waiting to access AIO worker submission queue. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as AioWorkerSubmissionQueue. 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/AioWorkerSubmissionQueue 
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 = 'AioWorkerSubmissionQueue'
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 = 'AioWorkerSubmissionQueue'
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

Related controls and signals

5.4 - LWLock: AutoFile

Waiting to update the postgresql.auto.conf file
PostgreSQL wait event dossier
ClassLWLock EventAutoFile VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to update the postgresql.auto.conf file

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/utils/activity/wait_event_names.txt:340. The instrumented operation is: Waiting to update the postgresql.auto.conf file. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as AutoFile. 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/AutoFile 
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 = 'AutoFile'
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 = 'AutoFile'
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

Related controls and signals

5.5 - LWLock: Autovacuum

Waiting to read or update the current state of autovacuum workers
PostgreSQL wait event dossier
ClassLWLock EventAutovacuum VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the current state of autovacuum workers

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/postmaster/autovacuum.c:611. The instrumented operation is: Waiting to read or update the current state of autovacuum workers. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as Autovacuum. 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/Autovacuum 
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 = 'Autovacuum'
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 = 'Autovacuum'
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

Related controls and signals

5.6 - LWLock: AutovacuumSchedule

Waiting to ensure that a table selected for autovacuum still needs vacuuming
PostgreSQL wait event dossier
ClassLWLock EventAutovacuumSchedule VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to ensure that a table selected for autovacuum still needs vacuuming

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/postmaster/autovacuum.c:2337. The instrumented operation is: Waiting to ensure that a table selected for autovacuum still needs vacuuming. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as AutovacuumSchedule. 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/AutovacuumSchedule 
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 = 'AutovacuumSchedule'
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 = 'AutovacuumSchedule'
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

Related controls and signals

5.7 - LWLock: BackgroundWorker

Waiting to read or update background worker state
PostgreSQL wait event dossier
ClassLWLock EventBackgroundWorker VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update background worker state

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/postmaster/bgworker.c:1070. The instrumented operation is: Waiting to read or update background worker state. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as BackgroundWorker. 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/BackgroundWorker 
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 = 'BackgroundWorker'
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 = 'BackgroundWorker'
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

Related controls and signals

5.8 - LWLock: BtreeVacuum

Waiting to read or update vacuum-related information for a B-tree index
PostgreSQL wait event dossier
ClassLWLock EventBtreeVacuum VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update vacuum-related information for a B-tree index

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/access/nbtree/nbtutils.c:3519. The instrumented operation is: Waiting to read or update vacuum-related information for a B-tree index. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as BtreeVacuum. 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/BtreeVacuum 
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 = 'BtreeVacuum'
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 = 'BtreeVacuum'
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

Related controls and signals

5.9 - LWLock: BufferContent

Waiting to access a data page in memory
PostgreSQL wait event dossier
ClassLWLock EventBufferContent 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 
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 = 'BufferContent'
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 = 'BufferContent'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Find the relations and statements shared by the waiters.
  2. Use page/index evidence to confirm a hotspot; do not infer one from the wait name alone.
  3. Spread hot keys, batch writes, or move maintenance away from the peak before considering capacity changes.

Source evidence

Related controls and signals

Typical incident pattern

A monotonically increasing key concentrates concurrent B-tree inserts on the rightmost leaf page; BufferContent rises with insert latency.

5.10 - LWLock: BufferMapping

Waiting to associate a data block with a buffer in the buffer pool
PostgreSQL wait event dossier
ClassLWLock EventBufferMapping VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to associate a data block with a buffer in the buffer pool

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

Trigger mechanism

The buffer manager hashes a relation/fork/block tag into a partition protected by BufferMappingLock. Lookup, insertion, eviction, and tag reassignment briefly take that partition lock; broad concurrent misses or buffer churn increase collisions.

Normal or trouble?

  • Normal: Brief waits occur when pages enter or leave shared buffers.
  • Investigate: Sustained recurrence suggests a working set that churns through shared buffers, many parallel scans, or concentrated access mapping into a few partitions.

Diagnostic SQL

Sessions waiting on LWLock/BufferMapping 
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 = 'BufferMapping'
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 = 'BufferMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Correlate with buffer hit ratio and read volume by database and statement.
  2. Look for a new scan, undersized cache, or concurrency jump.
  3. Reduce concurrent scan fan-out or fix the access path before simply enlarging shared_buffers.

Source evidence

Related controls and signals

Typical incident pattern

A plan regression launches many concurrent large scans; buffer-table partitions become hot while useful pages churn out of cache.

5.11 - LWLock: Checkpoint

Waiting to begin a checkpoint.
PostgreSQL wait event dossier
ClassLWLock EventCheckpoint VersionsPG 13 Evidence3 source location(s)

Official description

Waiting to begin a checkpoint.

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:765 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/access/transam/xlog.c:8957. The instrumented operation is: Waiting to begin a checkpoint. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as Checkpoint. 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/Checkpoint 
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 = 'Checkpoint'
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 = 'Checkpoint'
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

Related controls and signals

5.12 - LWLock: CheckpointerComm

Waiting to manage fsync requests
PostgreSQL wait event dossier
ClassLWLock EventCheckpointerComm VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to manage fsync requests

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/postmaster/checkpointer.c:1164. The instrumented operation is: Waiting to manage fsync requests. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as CheckpointerComm. 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/CheckpointerComm 
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 = 'CheckpointerComm'
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 = 'CheckpointerComm'
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

Related controls and signals

5.13 - LWLock: CommitTs

Waiting to read or update the last value set for a transaction commit timestamp
PostgreSQL wait event dossier
ClassLWLock EventCommitTs VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the last value set for a transaction commit timestamp

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/access/transam/commit_ts.c:206. The instrumented operation is: Waiting to read or update the last value set for a transaction commit timestamp. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as CommitTs. 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/CommitTs 
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 = 'CommitTs'
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 = 'CommitTs'
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

Related controls and signals

5.14 - 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

Related controls and signals

5.15 - LWLock: CommitTsSLRU

Waiting to access the commit timestamp SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventCommitTsSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the commit timestamp SLRU cache

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:172. The instrumented operation is: Waiting to access the commit timestamp SLRU cache. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as CommitTsSLRU. 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/CommitTsSLRU 
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 = 'CommitTsSLRU'
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 = 'CommitTsSLRU'
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

Related controls and signals

5.16 - LWLock: ControlFile

Waiting to read or update the pg_control file or create a new WAL file
PostgreSQL wait event dossier
ClassLWLock EventControlFile VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the pg_control file or create a new WAL file

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/access/transam/xlog.c:2723. The instrumented operation is: Waiting to read or update the pg_control file or create a new WAL file. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ControlFile. 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/ControlFile 
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 = 'ControlFile'
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 = 'ControlFile'
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

Related controls and signals

5.17 - LWLock: DSMRegistry

Waiting to read or update the dynamic shared memory registry
PostgreSQL wait event dossier
ClassLWLock EventDSMRegistry VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to read or update the dynamic shared memory registry

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/ipc/dsm_registry.c:98. The instrumented operation is: Waiting to read or update the dynamic shared memory registry. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as DSMRegistry. 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/DSMRegistry 
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 = 'DSMRegistry'
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 = 'DSMRegistry'
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

Related controls and signals

5.18 - LWLock: DSMRegistryDSA

Waiting to access dynamic shared memory registry’s dynamic shared memory allocator
PostgreSQL wait event dossier
ClassLWLock EventDSMRegistryDSA VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to access dynamic shared memory registry’s dynamic shared memory allocator

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:170. The instrumented operation is: Waiting to access dynamic shared memory registry’s dynamic shared memory allocator. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as DSMRegistryDSA. 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/DSMRegistryDSA 
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 = 'DSMRegistryDSA'
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 = 'DSMRegistryDSA'
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

Related controls and signals

5.19 - LWLock: DSMRegistryHash

Waiting to access dynamic shared memory registry’s shared hash table
PostgreSQL wait event dossier
ClassLWLock EventDSMRegistryHash VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to access dynamic shared memory registry’s shared hash table

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:171. The instrumented operation is: Waiting to access dynamic shared memory registry’s shared hash table. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as DSMRegistryHash. 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/DSMRegistryHash 
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 = 'DSMRegistryHash'
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 = 'DSMRegistryHash'
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

Related controls and signals

5.20 - LWLock: DynamicSharedMemoryControl

Waiting to read or update dynamic shared memory allocation information
PostgreSQL wait event dossier
ClassLWLock EventDynamicSharedMemoryControl VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update dynamic shared memory allocation information

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/ipc/dsm.c:549. The instrumented operation is: Waiting to read or update dynamic shared memory allocation information. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as DynamicSharedMemoryControl. 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/DynamicSharedMemoryControl 
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 = 'DynamicSharedMemoryControl'
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 = 'DynamicSharedMemoryControl'
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

Related controls and signals

5.21 - LWLock: InjectionPoint

Waiting to read or update information related to injection points
PostgreSQL wait event dossier
ClassLWLock EventInjectionPoint VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to read or update information related to injection points

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/utils/activity/wait_event_names.txt:353. The instrumented operation is: Waiting to read or update information related to injection points. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as InjectionPoint. 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/InjectionPoint 
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 = 'InjectionPoint'
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 = 'InjectionPoint'
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

Related controls and signals

5.22 - LWLock: LockFastPath

Waiting to read or update a process’ fast-path lock information
PostgreSQL wait event dossier
ClassLWLock EventLockFastPath VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update a process’ fast-path lock information

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:151. The instrumented operation is: Waiting to read or update a process’ fast-path lock information. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as LockFastPath. 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/LockFastPath 
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 = 'LockFastPath'
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 = 'LockFastPath'
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

Related controls and signals

5.23 - LWLock: LockManager

Waiting to read or update information about “heavyweight” locks
PostgreSQL wait event dossier
ClassLWLock EventLockManager 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 
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 = 'LockManager'
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 = 'LockManager'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Count pg_locks rows per PID and inspect the blocking tree.
  2. Identify statements touching many relations or partitions.
  3. Shorten transactions and reduce lock fan-out; raise max_locks_per_transaction only for genuine capacity errors.

Source evidence

Related controls and signals

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.

5.24 - LWLock: LogicalRepLauncherDSA

Waiting to access logical replication launcher’s dynamic shared memory allocator
PostgreSQL wait event dossier
ClassLWLock EventLogicalRepLauncherDSA VersionsPG 16-18 Evidence3 source location(s)

Official description

Waiting to access logical replication launcher’s dynamic shared memory allocator

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:168. The instrumented operation is: Waiting to access logical replication launcher’s dynamic shared memory allocator. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as LogicalRepLauncherDSA. 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/LogicalRepLauncherDSA 
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 = 'LogicalRepLauncherDSA'
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 = 'LogicalRepLauncherDSA'
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

Related controls and signals

5.25 - LWLock: LogicalRepLauncherHash

Waiting to access logical replication launcher’s shared hash table
PostgreSQL wait event dossier
ClassLWLock EventLogicalRepLauncherHash VersionsPG 16-18 Evidence3 source location(s)

Official description

Waiting to access logical replication launcher’s shared hash table

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:169. The instrumented operation is: Waiting to access logical replication launcher’s shared hash table. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as LogicalRepLauncherHash. 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/LogicalRepLauncherHash 
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 = 'LogicalRepLauncherHash'
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 = 'LogicalRepLauncherHash'
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

Related controls and signals

5.26 - LWLock: LogicalRepWorker

Waiting to read or update the state of logical replication workers
PostgreSQL wait event dossier
ClassLWLock EventLogicalRepWorker VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the state of logical replication workers

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/replication/logical/launcher.c:189. The instrumented operation is: Waiting to read or update the state of logical replication workers. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as LogicalRepWorker. 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/LogicalRepWorker 
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 = 'LogicalRepWorker'
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 = 'LogicalRepWorker'
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

Related controls and signals

5.27 - LWLock: MultiXactGen

Waiting to read or update shared multixact state
PostgreSQL wait event dossier
ClassLWLock EventMultiXactGen VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update shared multixact state

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/access/transam/multixact.c:738. The instrumented operation is: Waiting to read or update shared multixact state. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as MultiXactGen. 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/MultiXactGen 
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 = 'MultiXactGen'
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 = 'MultiXactGen'
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

Related controls and signals

5.28 - LWLock: MultiXactMemberBuffer

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

Official description

Waiting for I/O on a multixact member 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:144. The instrumented operation is: Waiting for I/O on a multixact member SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as MultiXactMemberBuffer. 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/MultiXactMemberBuffer 
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 = 'MultiXactMemberBuffer'
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 = 'MultiXactMemberBuffer'
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

Related controls and signals

5.29 - LWLock: MultiXactMemberSLRU

Waiting to access the multixact member SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventMultiXactMemberSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the multixact member SLRU cache

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

Trigger mechanism

This lock protects the SLRU cache for pg_multixact/members, which stores the transaction members of multitransaction IDs used by shared row locks. Concurrent row-lock creation and old member lookups meet here.

Normal or trouble?

  • Normal: Brief waits occur in workloads that use SELECT FOR SHARE/KEY SHARE or create multixacts through foreign-key checks.
  • Investigate: Sustained contention points to heavy shared row locking, multixact churn, lagging freeze, or slow pg_multixact storage.

Diagnostic SQL

Sessions waiting on LWLock/MultiXactMemberSLRU 
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 = 'MultiXactMemberSLRU'
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 = 'MultiXactMemberSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Find statements and tables creating many shared row locks.
  2. Check multixact age and autovacuum progress.
  3. Reduce lock fan-out and unblock multixact freeze; investigate member SLRU I/O if paired with buffer waits.

Source evidence

Related controls and signals

Typical incident pattern

A high-fan-out foreign-key workload locks many parent rows while a long transaction delays multixact cleanup, driving member-cache contention.

5.30 - LWLock: MultiXactOffsetBuffer

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

Official description

Waiting for I/O on a multixact offset 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:143. The instrumented operation is: Waiting for I/O on a multixact offset SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as MultiXactOffsetBuffer. 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/MultiXactOffsetBuffer 
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 = 'MultiXactOffsetBuffer'
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 = 'MultiXactOffsetBuffer'
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

Related controls and signals

5.31 - LWLock: MultiXactOffsetSLRU

Waiting to access the multixact offset SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventMultiXactOffsetSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the multixact offset SLRU cache

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:173. The instrumented operation is: Waiting to access the multixact offset SLRU cache. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as MultiXactOffsetSLRU. 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/MultiXactOffsetSLRU 
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 = 'MultiXactOffsetSLRU'
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 = 'MultiXactOffsetSLRU'
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

Related controls and signals

5.32 - LWLock: MultiXactTruncation

Waiting to read or truncate multixact information
PostgreSQL wait event dossier
ClassLWLock EventMultiXactTruncation VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or truncate multixact information

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/access/transam/multixact.c:2901. The instrumented operation is: Waiting to read or truncate multixact information. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as MultiXactTruncation. 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/MultiXactTruncation 
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 = 'MultiXactTruncation'
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 = 'MultiXactTruncation'
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

Related controls and signals

5.33 - LWLock: NotifyBuffer

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

Official description

Waiting for I/O on a NOTIFY message 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:145. The instrumented operation is: Waiting for I/O on a NOTIFY message SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as NotifyBuffer. 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/NotifyBuffer 
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 = 'NotifyBuffer'
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 = 'NotifyBuffer'
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

Related controls and signals

5.34 - LWLock: NotifyQueue

Waiting to read or update NOTIFY messages
PostgreSQL wait event dossier
ClassLWLock EventNotifyQueue VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update NOTIFY messages

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/commands/async.c:940. The instrumented operation is: Waiting to read or update NOTIFY messages. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as NotifyQueue. 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/NotifyQueue 
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 = 'NotifyQueue'
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 = 'NotifyQueue'
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

Related controls and signals

5.35 - LWLock: NotifyQueueTail

Waiting to update limit on NOTIFY message storage
PostgreSQL wait event dossier
ClassLWLock EventNotifyQueueTail VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to update limit on NOTIFY message storage

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/commands/async.c:2126. The instrumented operation is: Waiting to update limit on NOTIFY message storage. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as NotifyQueueTail. 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/NotifyQueueTail 
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 = 'NotifyQueueTail'
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 = 'NotifyQueueTail'
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

Related controls and signals

5.36 - LWLock: NotifySLRU

Waiting to access the NOTIFY message SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventNotifySLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the NOTIFY message SLRU cache

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:175. The instrumented operation is: Waiting to access the NOTIFY message SLRU cache. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as NotifySLRU. 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/NotifySLRU 
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 = 'NotifySLRU'
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 = 'NotifySLRU'
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

Related controls and signals

5.37 - LWLock: OidGen

Waiting to allocate a new OID
PostgreSQL wait event dossier
ClassLWLock EventOidGen VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to allocate a new OID

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/access/transam/varsup.c:563. The instrumented operation is: Waiting to allocate a new OID. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as OidGen. 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/OidGen 
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 = 'OidGen'
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 = 'OidGen'
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

Related controls and signals

5.38 - LWLock: OldSnapshotTimeMap

Waiting to read or update old snapshot control information.
PostgreSQL wait event dossier
ClassLWLock EventOldSnapshotTimeMap VersionsPG 13-16 Evidence2 source location(s)

Official description

Waiting to read or update old snapshot control information.

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:750 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/time/snapmgr.c:1758. The instrumented operation is: Waiting to read or update old snapshot control information. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as OldSnapshotTimeMap. 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/OldSnapshotTimeMap 
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 = 'OldSnapshotTimeMap'
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 = 'OldSnapshotTimeMap'
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

Related controls and signals

5.39 - LWLock: ParallelAppend

Waiting to choose the next subplan during Parallel Append plan execution
PostgreSQL wait event dossier
ClassLWLock EventParallelAppend VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to choose the next subplan during Parallel Append plan execution

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/executor/nodeAppend.c:69. The instrumented operation is: Waiting to choose the next subplan during Parallel Append plan execution. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ParallelAppend. 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/ParallelAppend 
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 = 'ParallelAppend'
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 = 'ParallelAppend'
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

Related controls and signals

5.40 - LWLock: ParallelBtreeScan

Waiting to synchronize workers during Parallel B-tree scan plan execution
PostgreSQL wait event dossier
ClassLWLock EventParallelBtreeScan VersionsPG 18 Evidence3 source location(s)

Official description

Waiting to synchronize workers during Parallel B-tree scan plan execution

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:156. The instrumented operation is: Waiting to synchronize workers during Parallel B-tree scan plan execution. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ParallelBtreeScan. 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/ParallelBtreeScan 
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 = 'ParallelBtreeScan'
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 = 'ParallelBtreeScan'
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

Related controls and signals

5.41 - LWLock: ParallelHashJoin

Waiting to synchronize workers during Parallel Hash Join plan execution
PostgreSQL wait event dossier
ClassLWLock EventParallelHashJoin VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to synchronize workers during Parallel Hash Join plan execution

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/executor/nodeHash.c:71. The instrumented operation is: Waiting to synchronize workers during Parallel Hash Join plan execution. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ParallelHashJoin. 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/ParallelHashJoin 
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 = 'ParallelHashJoin'
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 = 'ParallelHashJoin'
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

Related controls and signals

5.42 - LWLock: ParallelQueryDSA

Waiting for parallel query dynamic shared memory allocation
PostgreSQL wait event dossier
ClassLWLock EventParallelQueryDSA VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for parallel query dynamic shared memory allocation

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:157. The instrumented operation is: Waiting for parallel query dynamic shared memory allocation. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ParallelQueryDSA. 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/ParallelQueryDSA 
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 = 'ParallelQueryDSA'
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 = 'ParallelQueryDSA'
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

Related controls and signals

5.43 - LWLock: ParallelVacuumDSA

Waiting for parallel vacuum dynamic shared memory allocation
PostgreSQL wait event dossier
ClassLWLock EventParallelVacuumDSA VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting for parallel vacuum dynamic shared memory allocation

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:179. The instrumented operation is: Waiting for parallel vacuum dynamic shared memory allocation. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ParallelVacuumDSA. 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/ParallelVacuumDSA 
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 = 'ParallelVacuumDSA'
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 = 'ParallelVacuumDSA'
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

Related controls and signals

5.44 - LWLock: PerSessionDSA

Waiting for parallel query dynamic shared memory allocation
PostgreSQL wait event dossier
ClassLWLock EventPerSessionDSA VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for parallel query dynamic shared memory allocation

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:158. The instrumented operation is: Waiting for parallel query dynamic shared memory allocation. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PerSessionDSA. 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/PerSessionDSA 
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 = 'PerSessionDSA'
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 = 'PerSessionDSA'
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

Related controls and signals

5.45 - LWLock: PerSessionRecordType

Waiting to access a parallel query’s information about composite types
PostgreSQL wait event dossier
ClassLWLock EventPerSessionRecordType VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access a parallel query’s information about composite types

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:159. The instrumented operation is: Waiting to access a parallel query’s information about composite types. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PerSessionRecordType. 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/PerSessionRecordType 
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 = 'PerSessionRecordType'
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 = 'PerSessionRecordType'
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

Related controls and signals

5.46 - LWLock: PerSessionRecordTypmod

Waiting to access a parallel query’s information about type modifiers that identify anonymous record types
PostgreSQL wait event dossier
ClassLWLock EventPerSessionRecordTypmod VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access a parallel query’s information about type modifiers that identify anonymous record types

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:160. The instrumented operation is: Waiting to access a parallel query’s information about type modifiers that identify anonymous record types. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PerSessionRecordTypmod. 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/PerSessionRecordTypmod 
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 = 'PerSessionRecordTypmod'
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 = 'PerSessionRecordTypmod'
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

Related controls and signals

5.47 - LWLock: PerXactPredicateList

Waiting to access the list of predicate locks held by the current serializable transaction during a parallel query
PostgreSQL wait event dossier
ClassLWLock EventPerXactPredicateList VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the list of predicate locks held by the current serializable transaction during a parallel query

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:164. The instrumented operation is: Waiting to access the list of predicate locks held by the current serializable transaction during a parallel query. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PerXactPredicateList. 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/PerXactPredicateList 
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 = 'PerXactPredicateList'
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 = 'PerXactPredicateList'
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

Related controls and signals

5.48 - LWLock: PgStatsDSA

Waiting for stats dynamic shared memory allocator access
PostgreSQL wait event dossier
ClassLWLock EventPgStatsDSA VersionsPG 15-18 Evidence3 source location(s)

Official description

Waiting for stats dynamic shared memory allocator access

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:165. The instrumented operation is: Waiting for stats dynamic shared memory allocator access. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PgStatsDSA. 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/PgStatsDSA 
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 = 'PgStatsDSA'
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 = 'PgStatsDSA'
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

Related controls and signals

5.49 - LWLock: PgStatsData

Waiting for shared memory stats data access
PostgreSQL wait event dossier
ClassLWLock EventPgStatsData VersionsPG 15-18 Evidence3 source location(s)

Official description

Waiting for shared memory stats data access

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:167. The instrumented operation is: Waiting for shared memory stats data access. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PgStatsData. 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/PgStatsData 
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 = 'PgStatsData'
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 = 'PgStatsData'
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

Related controls and signals

5.50 - LWLock: PgStatsHash

Waiting for stats shared memory hash table access
PostgreSQL wait event dossier
ClassLWLock EventPgStatsHash VersionsPG 15-18 Evidence3 source location(s)

Official description

Waiting for stats shared memory hash table access

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:166. The instrumented operation is: Waiting for stats shared memory hash table access. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PgStatsHash. 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/PgStatsHash 
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 = 'PgStatsHash'
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 = 'PgStatsHash'
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

Related controls and signals

5.51 - LWLock: PredicateLockManager

Waiting to access predicate lock information used by serializable transactions
PostgreSQL wait event dossier
ClassLWLock EventPredicateLockManager VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access predicate lock information used by serializable transactions

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:154. The instrumented operation is: Waiting to access predicate lock information used by serializable transactions. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as PredicateLockManager. 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/PredicateLockManager 
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 = 'PredicateLockManager'
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 = 'PredicateLockManager'
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

Related controls and signals

5.52 - LWLock: ProcArray

Waiting to access the shared per-process data structures (typically, to get a snapshot or report a session’s transaction ID)
PostgreSQL wait event dossier
ClassLWLock EventProcArray VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the shared per-process data structures (typically, to get a snapshot or report a session’s transaction ID)

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

Trigger mechanism

ProcArrayLock protects the shared PGPROC/PGXACT arrays used for snapshots, transaction visibility, and transaction end. Snapshot acquisition and updates to process transaction state must briefly coordinate through it.

Normal or trouble?

  • Normal: Brief waits are expected on busy OLTP systems that start and finish many transactions.
  • Investigate: Persistent contention can accompany extreme connection counts, snapshot-heavy workloads, long transactions, or bursts of transaction completion.

Diagnostic SQL

Sessions waiting on LWLock/ProcArray 
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 = 'ProcArray'
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 = 'ProcArray'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Measure active backends and transaction age, not only total connections.
  2. Find long-running and idle-in-transaction sessions that keep visibility horizons old.
  3. Pool connections, shorten transactions, and avoid synchronized bursts of tiny transactions.

Source evidence

Related controls and signals

Typical incident pattern

An application reconnect storm creates thousands of short transactions while a reporting query holds an old snapshot, amplifying ProcArray traffic.

5.53 - LWLock: RelCacheInit

Waiting to read or update a pg_internal.init relation cache initialization file
PostgreSQL wait event dossier
ClassLWLock EventRelCacheInit VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update a pg_internal.init relation cache initialization file

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/utils/activity/wait_event_names.txt:323. The instrumented operation is: Waiting to read or update a pg_internal.init relation cache initialization file. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as RelCacheInit. 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/RelCacheInit 
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 = 'RelCacheInit'
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 = 'RelCacheInit'
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

Related controls and signals

5.54 - LWLock: RelationMapping

Waiting to read or update a pg_filenode.map file (used to track the filenode assignments of certain system catalogs)
PostgreSQL wait event dossier
ClassLWLock EventRelationMapping VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update a pg_filenode.map file (used to track the filenode assignments of certain system catalogs)

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/utils/activity/wait_event_names.txt:332. The instrumented operation is: Waiting to read or update a pg_filenode.map file (used to track the filenode assignments of certain system catalogs). LWLockAcquire could not immediately take the lightweight-lock tranche displayed as RelationMapping. 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/RelationMapping 
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 = 'RelationMapping'
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 = 'RelationMapping'
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

Related controls and signals

5.55 - LWLock: ReplicationOrigin

Waiting to create, drop or use a replication origin
PostgreSQL wait event dossier
ClassLWLock EventReplicationOrigin VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to create, drop or use a replication origin

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/replication/logical/origin.c:377. The instrumented operation is: Waiting to create, drop or use a replication origin. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ReplicationOrigin. 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/ReplicationOrigin 
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 = 'ReplicationOrigin'
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 = 'ReplicationOrigin'
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

Related controls and signals

5.56 - LWLock: ReplicationOriginState

Waiting to read or update the progress of one replication origin
PostgreSQL wait event dossier
ClassLWLock EventReplicationOriginState VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the progress of one replication origin

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/replication/logical/origin.c:557. The instrumented operation is: Waiting to read or update the progress of one replication origin. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ReplicationOriginState. 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/ReplicationOriginState 
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 = 'ReplicationOriginState'
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 = 'ReplicationOriginState'
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

Related controls and signals

5.57 - LWLock: ReplicationSlotAllocation

Waiting to allocate or free a replication slot
PostgreSQL wait event dossier
ClassLWLock EventReplicationSlotAllocation VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to allocate or free a replication slot

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/replication/logical/slotsync.c:543. The instrumented operation is: Waiting to allocate or free a replication slot. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ReplicationSlotAllocation. 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/ReplicationSlotAllocation 
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 = 'ReplicationSlotAllocation'
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 = 'ReplicationSlotAllocation'
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

Related controls and signals

5.58 - LWLock: ReplicationSlotControl

Waiting to read or update replication slot state
PostgreSQL wait event dossier
ClassLWLock EventReplicationSlotControl VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update replication slot state

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/replication/logical/logical.c:492. The instrumented operation is: Waiting to read or update replication slot state. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ReplicationSlotControl. 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/ReplicationSlotControl 
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 = 'ReplicationSlotControl'
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 = 'ReplicationSlotControl'
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

Related controls and signals

5.59 - LWLock: ReplicationSlotIO

Waiting for I/O on a replication slot
PostgreSQL wait event dossier
ClassLWLock EventReplicationSlotIO VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for I/O on a replication slot

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:150. The instrumented operation is: Waiting for I/O on a replication slot. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ReplicationSlotIO. 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/ReplicationSlotIO 
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 = 'ReplicationSlotIO'
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 = 'ReplicationSlotIO'
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

Related controls and signals

5.60 - LWLock: SInvalRead

Waiting to retrieve messages from the shared catalog invalidation queue
PostgreSQL wait event dossier
ClassLWLock EventSInvalRead VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to retrieve messages from the shared catalog invalidation queue

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/ipc/sinvaladt.c:497. The instrumented operation is: Waiting to retrieve messages from the shared catalog invalidation queue. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SInvalRead. 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/SInvalRead 
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 = 'SInvalRead'
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 = 'SInvalRead'
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

Related controls and signals

5.61 - LWLock: SInvalWrite

Waiting to add a message to the shared catalog invalidation queue
PostgreSQL wait event dossier
ClassLWLock EventSInvalWrite VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to add a message to the shared catalog invalidation queue

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/ipc/sinvaladt.c:290. The instrumented operation is: Waiting to add a message to the shared catalog invalidation queue. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SInvalWrite. 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/SInvalWrite 
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 = 'SInvalWrite'
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 = 'SInvalWrite'
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

Related controls and signals

5.62 - LWLock: SerialBuffer

Waiting for I/O on a serializable transaction conflict SLRU buffer
PostgreSQL wait event dossier
ClassLWLock EventSerialBuffer VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for I/O on a serializable transaction conflict 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:146. The instrumented operation is: Waiting for I/O on a serializable transaction conflict SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerialBuffer. 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/SerialBuffer 
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 = 'SerialBuffer'
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 = 'SerialBuffer'
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

Related controls and signals

5.63 - LWLock: SerialControl

Waiting to read or update shared pg_serial state
PostgreSQL wait event dossier
ClassLWLock EventSerialControl VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to read or update shared pg_serial state

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/predicate.c:835. The instrumented operation is: Waiting to read or update shared pg_serial state. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerialControl. 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/SerialControl 
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 = 'SerialControl'
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 = 'SerialControl'
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

Related controls and signals

5.64 - LWLock: SerialSLRU

Waiting to access the serializable transaction conflict SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventSerialSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the serializable transaction conflict SLRU cache

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:176. The instrumented operation is: Waiting to access the serializable transaction conflict SLRU cache. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerialSLRU. 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/SerialSLRU 
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 = 'SerialSLRU'
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 = 'SerialSLRU'
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

Related controls and signals

5.65 - LWLock: SerializableFinishedList

Waiting to access the list of finished serializable transactions
PostgreSQL wait event dossier
ClassLWLock EventSerializableFinishedList VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the list of finished serializable transactions

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/predicate.c:1507. The instrumented operation is: Waiting to access the list of finished serializable transactions. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerializableFinishedList. 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/SerializableFinishedList 
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 = 'SerializableFinishedList'
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 = 'SerializableFinishedList'
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

Related controls and signals

5.66 - LWLock: SerializablePredicateList

Waiting to access the list of predicate locks held by serializable transactions
PostgreSQL wait event dossier
ClassLWLock EventSerializablePredicateList VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the list of predicate locks held by serializable transactions

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/predicate.c:2220. The instrumented operation is: Waiting to access the list of predicate locks held by serializable transactions. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerializablePredicateList. 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/SerializablePredicateList 
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 = 'SerializablePredicateList'
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 = 'SerializablePredicateList'
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

Related controls and signals

5.67 - LWLock: SerializableXactHash

Waiting to read or update information about serializable transactions
PostgreSQL wait event dossier
ClassLWLock EventSerializableXactHash VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update information about serializable transactions

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/predicate.c:1462. The instrumented operation is: Waiting to read or update information about serializable transactions. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SerializableXactHash. 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/SerializableXactHash 
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 = 'SerializableXactHash'
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 = 'SerializableXactHash'
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

Related controls and signals

5.68 - LWLock: SharedTidBitmap

Waiting to access a shared TID bitmap during a parallel bitmap index scan
PostgreSQL wait event dossier
ClassLWLock EventSharedTidBitmap VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access a shared TID bitmap during a parallel bitmap index scan

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:162. The instrumented operation is: Waiting to access a shared TID bitmap during a parallel bitmap index scan. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SharedTidBitmap. 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/SharedTidBitmap 
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 = 'SharedTidBitmap'
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 = 'SharedTidBitmap'
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

Related controls and signals

5.69 - LWLock: SharedTupleStore

Waiting to access a shared tuple store during parallel query
PostgreSQL wait event dossier
ClassLWLock EventSharedTupleStore VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access a shared tuple store during parallel query

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:161. The instrumented operation is: Waiting to access a shared tuple store during parallel query. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SharedTupleStore. 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/SharedTupleStore 
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 = 'SharedTupleStore'
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 = 'SharedTupleStore'
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

Related controls and signals

5.70 - LWLock: ShmemIndex

Waiting to find or allocate space in shared memory
PostgreSQL wait event dossier
ClassLWLock EventShmemIndex VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to find or allocate space in shared memory

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/ipc/shmem.c:392. The instrumented operation is: Waiting to find or allocate space in shared memory. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as ShmemIndex. 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/ShmemIndex 
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 = 'ShmemIndex'
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 = 'ShmemIndex'
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

Related controls and signals

5.71 - LWLock: SubtransBuffer

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

Official description

Waiting for I/O on a sub-transaction 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:142. The instrumented operation is: Waiting for I/O on a sub-transaction SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SubtransBuffer. 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/SubtransBuffer 
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 = 'SubtransBuffer'
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 = 'SubtransBuffer'
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

Related controls and signals

5.72 - LWLock: SubtransSLRU

Waiting to access the sub-transaction SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventSubtransSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the sub-transaction SLRU cache

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:177. The instrumented operation is: Waiting to access the sub-transaction SLRU cache. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SubtransSLRU. 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/SubtransSLRU 
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 = 'SubtransSLRU'
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 = 'SubtransSLRU'
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

Related controls and signals

5.73 - LWLock: SyncRep

Waiting to read or update information about the state of synchronous replication
PostgreSQL wait event dossier
ClassLWLock EventSyncRep VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update information about the state of synchronous replication

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

Trigger mechanism

SyncRepLock protects synchronous-replication queues and shared sender state. Committers enqueue or inspect their wait position while WAL senders update which LSNs the configured synchronous standbys have acknowledged.

Normal or trouble?

  • Normal: Small bursts occur as synchronous commits queue and WAL senders publish acknowledgements.
  • Investigate: Sustained SyncRep LWLock contention is different from waiting for a standby acknowledgement: it means queue/state coordination itself is hot, usually under extreme commit concurrency or sender churn.

Diagnostic SQL

Sessions waiting on LWLock/SyncRep 
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 = 'SyncRep'
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 = 'SyncRep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Separate LWLock/SyncRep from IPC/SyncRep and replication-lag waits.
  2. Inspect synchronous standby health, sender churn, and commit rate.
  3. Stabilize replication and smooth commit bursts; change durability policy only with explicit incident authority.

Source evidence

Related controls and signals

Typical incident pattern

A standby flaps while a burst of synchronous committers repeatedly enters and leaves the wait queue, making queue coordination visible as LWLock/SyncRep.

5.74 - LWLock: SyncScan

Waiting to select the starting location of a synchronized table scan
PostgreSQL wait event dossier
ClassLWLock EventSyncScan VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to select the starting location of a synchronized table scan

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/access/common/syncscan.c:258. The instrumented operation is: Waiting to select the starting location of a synchronized table scan. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as SyncScan. 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/SyncScan 
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 = 'SyncScan'
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 = 'SyncScan'
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

Related controls and signals

5.75 - LWLock: TablespaceCreate

Waiting to create or drop a tablespace
PostgreSQL wait event dossier
ClassLWLock EventTablespaceCreate VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to create or drop a tablespace

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/commands/tablespace.c:138. The instrumented operation is: Waiting to create or drop a tablespace. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as TablespaceCreate. 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/TablespaceCreate 
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 = 'TablespaceCreate'
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 = 'TablespaceCreate'
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

Related controls and signals

5.76 - LWLock: TwoPhaseState

Waiting to read or update the state of prepared transactions
PostgreSQL wait event dossier
ClassLWLock EventTwoPhaseState VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to read or update the state of prepared transactions

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/access/transam/twophase.c:329. The instrumented operation is: Waiting to read or update the state of prepared transactions. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as TwoPhaseState. 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/TwoPhaseState 
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 = 'TwoPhaseState'
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 = 'TwoPhaseState'
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

Related controls and signals

5.77 - LWLock: WALBufMapping

Waiting to replace a page in WAL buffers
PostgreSQL wait event dossier
ClassLWLock EventWALBufMapping VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to replace a page in WAL buffers

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

Trigger mechanism

WALBufMappingLock coordinates the mapping between WAL page numbers and the finite wal_buffers slots. A backend needs it when advancing to or replacing a WAL buffer page.

Normal or trouble?

  • Normal: Short waits appear as WAL generation advances through buffer pages.
  • Investigate: Sustained contention suggests WAL generation is turning over buffers faster than the write path advances, often during write bursts or checkpoints.

Diagnostic SQL

Sessions waiting on LWLock/WALBufMapping 
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 = 'WALBufMapping'
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 = 'WALBufMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Correlate with WAL bytes, WAL writes, and checkpoint timing.
  2. Check whether wal_buffers is repeatedly exhausted during bursts.
  3. Smooth write bursts and fix WAL device latency before tuning buffer size.

Source evidence

Related controls and signals

Typical incident pattern

A bulk load saturates WAL generation while the WAL device stalls, forcing frequent WAL buffer remapping.

5.78 - LWLock: WALInsert

Waiting to insert WAL data into a memory buffer
PostgreSQL wait event dossier
ClassLWLock EventWALInsert VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to insert WAL data into a memory buffer

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

Trigger mechanism

A backend must hold one of the WAL insertion locks while reserving and copying a WAL record into shared WAL buffers. High concurrent WAL producers can queue when insertion critical sections lengthen.

Normal or trouble?

  • Normal: Transient waits are normal during concurrent writes and commit bursts.
  • Investigate: A recurring foreground pile-up indicates WAL insertion has become a serialization point, often with very high write concurrency, full-page images, or slow buffer turnover.

Diagnostic SQL

Sessions waiting on LWLock/WALInsert 
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 = 'WALInsert'
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 = 'WALInsert'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Rank statements by WAL generation and call rate.
  2. Check checkpoint/full-page-image timing and concurrent writer count.
  3. Batch tiny writes, reduce needless index churn, and address WAL write latency.

Source evidence

Related controls and signals

Typical incident pattern

A fan-out job issues many single-row commits immediately after a checkpoint; full-page images and writer concurrency turn WAL insertion into the bottleneck.

5.79 - LWLock: WALSummarizer

Waiting to read or update WAL summarization state
PostgreSQL wait event dossier
ClassLWLock EventWALSummarizer VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to read or update WAL summarization state

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/postmaster/walsummarizer.c:273. The instrumented operation is: Waiting to read or update WAL summarization state. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as WALSummarizer. 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/WALSummarizer 
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 = 'WALSummarizer'
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 = 'WALSummarizer'
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

Related controls and signals

5.80 - LWLock: WALWrite

Waiting for WAL buffers to be written to disk
PostgreSQL wait event dossier
ClassLWLock EventWALWrite VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting for WAL buffers to be written to disk

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

Trigger mechanism

WALWriteLock serializes progress that writes shared WAL buffers and advances the written/flushed WAL positions. A waiter is queued behind the backend currently performing or coordinating that work.

Normal or trouble?

  • Normal: Brief waits occur when concurrent committers help write WAL.
  • Investigate: Sustained WALWrite with commit latency usually means the WAL write path is slow or cannot absorb the generated WAL rate.

Diagnostic SQL

Sessions waiting on LWLock/WALWrite 
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 = 'WALWrite'
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 = 'WALWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Compare WAL write and sync time with commit latency.
  2. Check the WAL filesystem/device, virtualization throttling, and checkpoint overlap.
  3. Reduce burstiness; tune wal_writer settings only after storage evidence confirms the path.

Source evidence

Related controls and signals

Typical incident pattern

A cloud volume hits its burst-credit ceiling; WAL writes lengthen, committers queue on WALWrite, and synchronous commits slow together.

5.81 - LWLock: WaitEventCustom

Waiting to read or update custom wait events information
PostgreSQL wait event dossier
ClassLWLock EventWaitEventCustom VersionsPG 17-18 Evidence3 source location(s)

Official description

Waiting to read or update custom wait events information

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/utils/activity/wait_event.c:193. The instrumented operation is: Waiting to read or update custom wait events information. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as WaitEventCustom. 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/WaitEventCustom 
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 = 'WaitEventCustom'
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 = 'WaitEventCustom'
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

Related controls and signals

5.82 - LWLock: WrapLimitsVacuum

Waiting to update limits on transaction id and multixact consumption
PostgreSQL wait event dossier
ClassLWLock EventWrapLimitsVacuum VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to update limits on transaction id and multixact consumption

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/commands/vacuum.c:1858. The instrumented operation is: Waiting to update limits on transaction id and multixact consumption. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as WrapLimitsVacuum. 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/WrapLimitsVacuum 
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 = 'WrapLimitsVacuum'
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 = 'WrapLimitsVacuum'
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

Related controls and signals

5.83 - LWLock: XactBuffer

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

Official description

Waiting for I/O on a transaction status 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:140. The instrumented operation is: Waiting for I/O on a transaction status SLRU buffer. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as XactBuffer. 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/XactBuffer 
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 = 'XactBuffer'
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 = 'XactBuffer'
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

Related controls and signals

5.84 - LWLock: XactSLRU

Waiting to access the transaction status SLRU cache
PostgreSQL wait event dossier
ClassLWLock EventXactSLRU VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to access the transaction status SLRU cache

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

Trigger mechanism

The transaction-status SLRU lock protects pg_xact cache metadata and pages while PostgreSQL reads or updates transaction commit status. Visibility checks for uncached or old XIDs can bring this path into the foreground.

Normal or trouble?

  • Normal: Short waits accompany transaction completion and occasional pg_xact cache misses.
  • Investigate: Persistent waits can indicate transaction-status cache churn, access to very old tuples, or storage latency on the pg_xact path.

Diagnostic SQL

Sessions waiting on LWLock/XactSLRU 
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 = 'XactSLRU'
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 = 'XactSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check old transactions and vacuum/freeze health.
  2. Correlate with XactBuffer and pg_xact I/O waits.
  3. Remove visibility-horizon blockers and restore vacuum progress before changing SLRU-related capacity.

Source evidence

Related controls and signals

Typical incident pattern

A long-lived snapshot prevents cleanup while queries revisit cold, old tuple versions, creating pg_xact cache churn and XactSLRU contention.

5.85 - LWLock: XactTruncation

Waiting to execute pg_xact_status or update the oldest transaction ID available to it
PostgreSQL wait event dossier
ClassLWLock EventXactTruncation VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to execute pg_xact_status or update the oldest transaction ID available to it

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/access/transam/varsup.c:357. The instrumented operation is: Waiting to execute pg_xact_status or update the oldest transaction ID available to it. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as XactTruncation. 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/XactTruncation 
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 = 'XactTruncation'
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 = 'XactTruncation'
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

Related controls and signals

5.86 - LWLock: XidGen

Waiting to allocate a new transaction ID
PostgreSQL wait event dossier
ClassLWLock EventXidGen VersionsPG 13-18 Evidence3 source location(s)

Official description

Waiting to allocate a new transaction ID

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/access/transam/varsup.c:105. The instrumented operation is: Waiting to allocate a new transaction ID. LWLockAcquire could not immediately take the lightweight-lock tranche displayed as XidGen. 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/XidGen 
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 = 'XidGen'
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 = 'XidGen'
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

Related controls and signals

6 - I/O waits

File reads, writes, synchronization, allocation, and asynchronous I/O completion.

IO means PostgreSQL has instrumented a file operation and the backend cannot continue until the kernel or another I/O worker makes progress. It says which PostgreSQL file path is involved; it does not, by itself, prove the storage is slow.

Read event + operation + workload phase

Names usually encode both object and operation: DataFileRead, WalSync, SlruWrite, ReorderBufferRead. Ask whether the workload should be performing that operation now, then compare duration and concurrency with pg_stat_io (PG16+) and operating-system latency.

  • Normal: scans read data files, checkpoints sync dirty files, backups read/write, recovery reads WAL.
  • Watch: the same foreground I/O event persists in consecutive samples and device latency or query latency rises.
  • Urgent: many backends queue behind sync/write completion, errors appear, or the affected path reaches saturation/throttling.

Events to recognize

Event First interpretation
DataFileRead Cache miss or scan reading relation data
DataFileWrite Backend/checkpoint path writing relation data
DataFileSync Relation changes are being made durable
WalWrite WAL bytes are being written
WalSync WAL durability boundary is waiting on fsync/fdatasync
SlruRead Transaction-related SLRU page read
BuffileRead Temp/spill file read
AioIoCompletion PG18 AIO work has not completed yet

PG16+ I/O context 

SELECT backend_type, object, context,
       reads, read_time, writes, write_time,
       writebacks, fsyncs, fsync_time
FROM pg_stat_io
ORDER BY coalesce(read_time, 0) + coalesce(write_time, 0) + coalesce(fsync_time, 0) DESC;

Common misreads

  • A high count of DataFileRead during an intentional sequential scan can be healthy throughput.
  • WalWrite and LWLock WALWrite are different: one is a file operation, the other internal coordination.
  • Average device latency can hide a saturated single WAL volume or tail-latency spikes.
  • Raising cache size cannot fix every read wait; poor plans and cold one-time scans may simply displace useful pages.

6.1 - IO: AioIoCompletion

Waiting for another process to complete IO
PostgreSQL wait event dossier
ClassIO EventAioIoCompletion VersionsPG 18 Evidence2 source location(s)

Official description

Waiting for another process to complete IO

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_AIO_IO_COMPLETION at src/backend/storage/aio/aio.c:643 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:196. The instrumented operation is: Waiting for another process to complete IO. PostgreSQL reports AioIoCompletion around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/AioIoCompletion 
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 = 'IO'
  AND wait_event = 'AioIoCompletion'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoCompletion'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.2 - IO: AioIoUringExecution

Waiting for IO execution via io_uring
PostgreSQL wait event dossier
ClassIO EventAioIoUringExecution VersionsPG 18 Evidence2 source location(s)

Official description

Waiting for IO execution via io_uring

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_AIO_IO_URING_EXECUTION at src/backend/storage/aio/method_io_uring.c:624 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:198. The instrumented operation is: Waiting for IO execution via io_uring. PostgreSQL reports AioIoUringExecution around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/AioIoUringExecution 
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 = 'IO'
  AND wait_event = 'AioIoUringExecution'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoUringExecution'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.3 - IO: AioIoUringSubmit

Waiting for IO submission via io_uring
PostgreSQL wait event dossier
ClassIO EventAioIoUringSubmit VersionsPG 18 Evidence2 source location(s)

Official description

Waiting for IO submission via io_uring

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_AIO_IO_URING_SUBMIT at src/backend/storage/aio/method_io_uring.c:451 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:197. The instrumented operation is: Waiting for IO submission via io_uring. PostgreSQL reports AioIoUringSubmit around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/AioIoUringSubmit 
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 = 'IO'
  AND wait_event = 'AioIoUringSubmit'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoUringSubmit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.4 - IO: BasebackupRead

Waiting for base backup to read from a file
PostgreSQL wait event dossier
ClassIO EventBasebackupRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for base backup to read from a file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BaseBackupRead (PG 14-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_READ at src/backend/backup/basebackup.c:1837 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:541. The instrumented operation is: Waiting for base backup to read from a file. PostgreSQL reports BasebackupRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BasebackupRead 
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 = 'IO'
  AND wait_event = 'BasebackupRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.5 - IO: BasebackupSync

Waiting for data written by a base backup to reach durable storage
PostgreSQL wait event dossier
ClassIO EventBasebackupSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for data written by a base backup to reach durable storage

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BaseBackupSync (PG 15-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_SYNC at src/backend/backup/basebackup_server.c:206 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:544. The instrumented operation is: Waiting for data written by a base backup to reach durable storage. PostgreSQL reports BasebackupSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BasebackupSync 
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 = 'IO'
  AND wait_event = 'BasebackupSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.6 - IO: BasebackupWrite

Waiting for base backup to write to a file
PostgreSQL wait event dossier
ClassIO EventBasebackupWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for base backup to write to a file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BaseBackupWrite (PG 15-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_WRITE at src/backend/backup/basebackup_server.c:168 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:547. The instrumented operation is: Waiting for base backup to write to a file. PostgreSQL reports BasebackupWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BasebackupWrite 
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 = 'IO'
  AND wait_event = 'BasebackupWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.7 - IO: BuffileRead

Waiting for a read from a buffered file
PostgreSQL wait event dossier
ClassIO EventBuffileRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read from a buffered file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BufFileRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_READ at src/backend/storage/file/buffile.c:464 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:550. The instrumented operation is: Waiting for a read from a buffered file. PostgreSQL reports BuffileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BuffileRead 
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 = 'IO'
  AND wait_event = 'BuffileRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.8 - IO: BuffileTruncate

Waiting for a buffered file to be truncated
PostgreSQL wait event dossier
ClassIO EventBuffileTruncate VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a buffered file to be truncated

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BufFileTruncate (PG 14-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_TRUNCATE at src/backend/storage/file/buffile.c:989 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:556. The instrumented operation is: Waiting for a buffered file to be truncated. PostgreSQL reports BuffileTruncate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BuffileTruncate 
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 = 'IO'
  AND wait_event = 'BuffileTruncate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.9 - IO: BuffileWrite

Waiting for a write to a buffered file
PostgreSQL wait event dossier
ClassIO EventBuffileWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write to a buffered file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/BufFileWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_WRITE at src/backend/storage/file/buffile.c:541 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:553. The instrumented operation is: Waiting for a write to a buffered file. PostgreSQL reports BuffileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/BuffileWrite 
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 = 'IO'
  AND wait_event = 'BuffileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.10 - IO: ControlFileRead

Waiting for a read from the pg_control file
PostgreSQL wait event dossier
ClassIO EventControlFileRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read from the pg_control file

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

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_READ at src/backend/access/transam/xlog.c:4362 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:205. The instrumented operation is: Waiting for a read from the pg_control file. PostgreSQL reports ControlFileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ControlFileRead 
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 = 'IO'
  AND wait_event = 'ControlFileRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.11 - IO: ControlFileSync

Waiting for the pg_control file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventControlFileSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for the pg_control file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_SYNC at src/backend/access/transam/xlog.c:4328 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:206. The instrumented operation is: Waiting for the pg_control file to reach durable storage. PostgreSQL reports ControlFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ControlFileSync 
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 = 'IO'
  AND wait_event = 'ControlFileSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.12 - IO: ControlFileSyncUpdate

Waiting for an update to the pg_control file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventControlFileSyncUpdate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an update to the pg_control file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_SYNC_UPDATE at src/common/controldata_utils.c:259 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:207. The instrumented operation is: Waiting for an update to the pg_control file to reach durable storage. PostgreSQL reports ControlFileSyncUpdate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ControlFileSyncUpdate 
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 = 'IO'
  AND wait_event = 'ControlFileSyncUpdate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileSyncUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.13 - IO: ControlFileWrite

Waiting for a write to the pg_control file
PostgreSQL wait event dossier
ClassIO EventControlFileWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write to the pg_control file

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

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_WRITE at src/backend/access/transam/xlog.c:4315 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:208. The instrumented operation is: Waiting for a write to the pg_control file. PostgreSQL reports ControlFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ControlFileWrite 
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 = 'IO'
  AND wait_event = 'ControlFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.14 - IO: ControlFileWriteUpdate

Waiting for a write to update the pg_control file
PostgreSQL wait event dossier
ClassIO EventControlFileWriteUpdate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write to update the pg_control file

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

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_WRITE_UPDATE at src/common/controldata_utils.c:235 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:209. The instrumented operation is: Waiting for a write to update the pg_control file. PostgreSQL reports ControlFileWriteUpdate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ControlFileWriteUpdate 
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 = 'IO'
  AND wait_event = 'ControlFileWriteUpdate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileWriteUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.15 - IO: CopyFileCopy

Waiting for a file copy operation
PostgreSQL wait event dossier
ClassIO EventCopyFileCopy VersionsPG 18 Evidence2 source location(s)

Official description

Waiting for a file copy operation

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_COPY_FILE_COPY at src/backend/storage/file/copydir.c:270 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:210. The instrumented operation is: Waiting for a file copy operation. PostgreSQL reports CopyFileCopy around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/CopyFileCopy 
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 = 'IO'
  AND wait_event = 'CopyFileCopy'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'CopyFileCopy'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.16 - IO: CopyFileRead

Waiting for a read during a file copy operation
PostgreSQL wait event dossier
ClassIO EventCopyFileRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read during a file copy operation

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

Trigger mechanism

WAIT_EVENT_COPY_FILE_READ at src/backend/storage/file/copydir.c:195 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:211. The instrumented operation is: Waiting for a read during a file copy operation. PostgreSQL reports CopyFileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/CopyFileRead 
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 = 'IO'
  AND wait_event = 'CopyFileRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'CopyFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.17 - IO: CopyFileWrite

Waiting for a write during a file copy operation
PostgreSQL wait event dossier
ClassIO EventCopyFileWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write during a file copy operation

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

Trigger mechanism

WAIT_EVENT_COPY_FILE_WRITE at src/backend/storage/file/copydir.c:205 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:212. The instrumented operation is: Waiting for a write during a file copy operation. PostgreSQL reports CopyFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/CopyFileWrite 
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 = 'IO'
  AND wait_event = 'CopyFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'CopyFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.18 - IO: DataFileExtend

Waiting for a relation data file to be extended
PostgreSQL wait event dossier
ClassIO EventDataFileExtend VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a relation data file to be extended

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_EXTEND at src/backend/storage/smgr/md.c:512 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:213. The instrumented operation is: Waiting for a relation data file to be extended. PostgreSQL reports DataFileExtend around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileExtend 
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 = 'IO'
  AND wait_event = 'DataFileExtend'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileExtend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.19 - IO: DataFileFlush

Waiting for a relation data file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventDataFileFlush VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a relation data file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_FLUSH at src/backend/storage/smgr/md.c:1208 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:214. The instrumented operation is: Waiting for a relation data file to reach durable storage. PostgreSQL reports DataFileFlush around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileFlush 
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 = 'IO'
  AND wait_event = 'DataFileFlush'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileFlush'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.20 - IO: DataFileImmediateSync

Waiting for an immediate synchronization of a relation data file to durable storage
PostgreSQL wait event dossier
ClassIO EventDataFileImmediateSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an immediate synchronization of a relation data file to durable storage

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_IMMEDIATE_SYNC at src/backend/storage/smgr/md.c:1466 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:215. The instrumented operation is: Waiting for an immediate synchronization of a relation data file to durable storage. PostgreSQL reports DataFileImmediateSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileImmediateSync 
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 = 'IO'
  AND wait_event = 'DataFileImmediateSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileImmediateSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.21 - IO: DataFilePrefetch

Waiting for an asynchronous prefetch from a relation data file
PostgreSQL wait event dossier
ClassIO EventDataFilePrefetch VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an asynchronous prefetch from a relation data file

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_PREFETCH at src/backend/storage/smgr/md.c:767 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:216. The instrumented operation is: Waiting for an asynchronous prefetch from a relation data file. PostgreSQL reports DataFilePrefetch around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFilePrefetch 
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 = 'IO'
  AND wait_event = 'DataFilePrefetch'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFilePrefetch'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.22 - IO: DataFileRead

Waiting for a read from a relation data file
PostgreSQL wait event dossier
ClassIO EventDataFileRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read from a relation data file

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_READ at src/backend/storage/aio/aio_io.c:127 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:217. The instrumented operation is: Waiting for a read from a relation data file. PostgreSQL reports DataFileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileRead 
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 = 'IO'
  AND wait_event = 'DataFileRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.23 - IO: DataFileSync

Waiting for changes to a relation data file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventDataFileSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for changes to a relation data file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_SYNC at src/backend/storage/smgr/md.c:1526 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:218. The instrumented operation is: Waiting for changes to a relation data file to reach durable storage. PostgreSQL reports DataFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileSync 
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 = 'IO'
  AND wait_event = 'DataFileSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.24 - IO: DataFileTruncate

Waiting for a relation data file to be truncated
PostgreSQL wait event dossier
ClassIO EventDataFileTruncate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a relation data file to be truncated

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_TRUNCATE at src/backend/storage/smgr/md.c:1329 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:219. The instrumented operation is: Waiting for a relation data file to be truncated. PostgreSQL reports DataFileTruncate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileTruncate 
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 = 'IO'
  AND wait_event = 'DataFileTruncate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.25 - IO: DataFileWrite

Waiting for a write to a relation data file
PostgreSQL wait event dossier
ClassIO EventDataFileWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write to a relation data file

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

Trigger mechanism

WAIT_EVENT_DATA_FILE_WRITE at src/backend/storage/aio/aio_io.c:134 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:220. The instrumented operation is: Waiting for a write to a relation data file. PostgreSQL reports DataFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DataFileWrite 
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 = 'IO'
  AND wait_event = 'DataFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DataFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.26 - IO: DsmAllocate

Waiting for a dynamic shared memory segment to be allocated
PostgreSQL wait event dossier
ClassIO EventDsmAllocate VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a dynamic shared memory segment to be allocated

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/DSMAllocate (PG 16)

Trigger mechanism

WAIT_EVENT_DSM_ALLOCATE at src/backend/storage/ipc/dsm_impl.c:366 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:604. The instrumented operation is: Waiting for a dynamic shared memory segment to be allocated. PostgreSQL reports DsmAllocate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DsmAllocate 
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 = 'IO'
  AND wait_event = 'DsmAllocate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DsmAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.27 - IO: DsmFillZeroWrite

Waiting to fill a dynamic shared memory backing file with zeroes
PostgreSQL wait event dossier
ClassIO EventDsmFillZeroWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting to fill a dynamic shared memory backing file with zeroes

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/DSMFillZeroWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_DSM_FILL_ZERO_WRITE at src/backend/storage/ipc/dsm_impl.c:891 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:607. The instrumented operation is: Waiting to fill a dynamic shared memory backing file with zeroes. PostgreSQL reports DsmFillZeroWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/DsmFillZeroWrite 
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 = 'IO'
  AND wait_event = 'DsmFillZeroWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'DsmFillZeroWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.28 - IO: LockFileAddtodatadirRead

Waiting for a read while adding a line to the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileAddtodatadirRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read while adding a line to the data directory lock file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/LockFileAddToDataDirRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_READ at src/backend/utils/init/miscinit.c:1586 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:610. The instrumented operation is: Waiting for a read while adding a line to the data directory lock file. PostgreSQL reports LockFileAddtodatadirRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileAddtodatadirRead 
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 = 'IO'
  AND wait_event = 'LockFileAddtodatadirRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileAddtodatadirRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.29 - IO: LockFileAddtodatadirSync

Waiting for data to reach durable storage while adding a line to the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileAddtodatadirSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for data to reach durable storage while adding a line to the data directory lock file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/LockFileAddToDataDirSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_SYNC at src/backend/utils/init/miscinit.c:1663 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:613. The instrumented operation is: Waiting for data to reach durable storage while adding a line to the data directory lock file. PostgreSQL reports LockFileAddtodatadirSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileAddtodatadirSync 
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 = 'IO'
  AND wait_event = 'LockFileAddtodatadirSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileAddtodatadirSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.30 - IO: LockFileAddtodatadirWrite

Waiting for a write while adding a line to the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileAddtodatadirWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write while adding a line to the data directory lock file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/LockFileAddToDataDirWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_WRITE at src/backend/utils/init/miscinit.c:1648 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:616. The instrumented operation is: Waiting for a write while adding a line to the data directory lock file. PostgreSQL reports LockFileAddtodatadirWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileAddtodatadirWrite 
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 = 'IO'
  AND wait_event = 'LockFileAddtodatadirWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileAddtodatadirWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.31 - IO: LockFileCreateRead

Waiting to read while creating the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileCreateRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to read while creating the data directory lock file

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

Trigger mechanism

WAIT_EVENT_LOCK_FILE_CREATE_READ at src/backend/utils/init/miscinit.c:1302 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:226. The instrumented operation is: Waiting to read while creating the data directory lock file. PostgreSQL reports LockFileCreateRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileCreateRead 
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 = 'IO'
  AND wait_event = 'LockFileCreateRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileCreateRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.32 - IO: LockFileCreateSync

Waiting for data to reach durable storage while creating the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileCreateSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for data to reach durable storage while creating the data directory lock file

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

Trigger mechanism

WAIT_EVENT_LOCK_FILE_CREATE_SYNC at src/backend/utils/init/miscinit.c:1465 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:227. The instrumented operation is: Waiting for data to reach durable storage while creating the data directory lock file. PostgreSQL reports LockFileCreateSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileCreateSync 
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 = 'IO'
  AND wait_event = 'LockFileCreateSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileCreateSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.33 - IO: LockFileCreateWrite

Waiting for a write while creating the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileCreateWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write while creating the data directory lock file

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

Trigger mechanism

WAIT_EVENT_LOCK_FILE_CREATE_WRITE at src/backend/utils/init/miscinit.c:1450 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:228. The instrumented operation is: Waiting for a write while creating the data directory lock file. PostgreSQL reports LockFileCreateWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileCreateWrite 
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 = 'IO'
  AND wait_event = 'LockFileCreateWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileCreateWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.34 - IO: LockFileRecheckdatadirRead

Waiting for a read during recheck of the data directory lock file
PostgreSQL wait event dossier
ClassIO EventLockFileRecheckdatadirRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read during recheck of the data directory lock file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/LockFileReCheckDataDirRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_LOCK_FILE_RECHECKDATADIR_READ at src/backend/utils/init/miscinit.c:1728 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:628. The instrumented operation is: Waiting for a read during recheck of the data directory lock file. PostgreSQL reports LockFileRecheckdatadirRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LockFileRecheckdatadirRead 
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 = 'IO'
  AND wait_event = 'LockFileRecheckdatadirRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LockFileRecheckdatadirRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.35 - IO: LogicalChangesRead

Waiting for a read from a logical changes file.
PostgreSQL wait event dossier
ClassIO EventLogicalChangesRead VersionsPG 14 Evidence1 source location(s)

Official description

Waiting for a read from a logical changes file.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ — — — —

Trigger mechanism

The catalog identity is present, but source audit found no live reporter in 14. Known active ranges: none. The definition location below is retained as negative evidence; this exact release cannot emit the event from a core code path. Evidence: pgsql-hackers confirmation.

Normal or trouble?

  • Normal: No live core occurrence is expected on the audited release.
  • Investigate: If telemetry shows it, verify the exact patch version, extension origin, and whether the sample is stale or came from a different server.

Diagnostic SQL

Sessions waiting on IO/LogicalChangesRead 
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 = 'IO'
  AND wait_event = 'LogicalChangesRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalChangesRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.36 - IO: LogicalChangesWrite

Waiting for a write to a logical changes file.
PostgreSQL wait event dossier
ClassIO EventLogicalChangesWrite VersionsPG 14 Evidence1 source location(s)

Official description

Waiting for a write to a logical changes file.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ — — — —

Trigger mechanism

The catalog identity is present, but source audit found no live reporter in 14. Known active ranges: none. The definition location below is retained as negative evidence; this exact release cannot emit the event from a core code path. Evidence: pgsql-hackers confirmation.

Normal or trouble?

  • Normal: No live core occurrence is expected on the audited release.
  • Investigate: If telemetry shows it, verify the exact patch version, extension origin, and whether the sample is stale or came from a different server.

Diagnostic SQL

Sessions waiting on IO/LogicalChangesWrite 
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 = 'IO'
  AND wait_event = 'LogicalChangesWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalChangesWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.37 - IO: LogicalRewriteCheckpointSync

Waiting for logical rewrite mappings to reach durable storage during a checkpoint
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteCheckpointSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for logical rewrite mappings to reach durable storage during a checkpoint

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_CHECKPOINT_SYNC at src/backend/access/heap/rewriteheap.c:1236 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:230. The instrumented operation is: Waiting for logical rewrite mappings to reach durable storage during a checkpoint. PostgreSQL reports LogicalRewriteCheckpointSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteCheckpointSync 
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 = 'IO'
  AND wait_event = 'LogicalRewriteCheckpointSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteCheckpointSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.38 - IO: LogicalRewriteMappingSync

Waiting for mapping data to reach durable storage during a logical rewrite
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteMappingSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for mapping data to reach durable storage during a logical rewrite

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_MAPPING_SYNC at src/backend/access/heap/rewriteheap.c:1131 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:231. The instrumented operation is: Waiting for mapping data to reach durable storage during a logical rewrite. PostgreSQL reports LogicalRewriteMappingSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteMappingSync 
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 = 'IO'
  AND wait_event = 'LogicalRewriteMappingSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteMappingSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.39 - IO: LogicalRewriteMappingWrite

Waiting for a write of mapping data during a logical rewrite
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteMappingWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of mapping data during a logical rewrite

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_MAPPING_WRITE at src/backend/access/heap/rewriteheap.c:1114 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:232. The instrumented operation is: Waiting for a write of mapping data during a logical rewrite. PostgreSQL reports LogicalRewriteMappingWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteMappingWrite 
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 = 'IO'
  AND wait_event = 'LogicalRewriteMappingWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteMappingWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.40 - IO: LogicalRewriteSync

Waiting for logical rewrite mappings to reach durable storage
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for logical rewrite mappings to reach durable storage

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_SYNC at src/backend/access/heap/rewriteheap.c:922 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:233. The instrumented operation is: Waiting for logical rewrite mappings to reach durable storage. PostgreSQL reports LogicalRewriteSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteSync 
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 = 'IO'
  AND wait_event = 'LogicalRewriteSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.41 - IO: LogicalRewriteTruncate

Waiting for truncate of mapping data during a logical rewrite
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteTruncate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for truncate of mapping data during a logical rewrite

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_TRUNCATE at src/backend/access/heap/rewriteheap.c:1100 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:234. The instrumented operation is: Waiting for truncate of mapping data during a logical rewrite. PostgreSQL reports LogicalRewriteTruncate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteTruncate 
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 = 'IO'
  AND wait_event = 'LogicalRewriteTruncate'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.42 - IO: LogicalRewriteWrite

Waiting for a write of logical rewrite mappings
PostgreSQL wait event dossier
ClassIO EventLogicalRewriteWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of logical rewrite mappings

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

Trigger mechanism

WAIT_EVENT_LOGICAL_REWRITE_WRITE at src/backend/access/heap/rewriteheap.c:881 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:235. The instrumented operation is: Waiting for a write of logical rewrite mappings. PostgreSQL reports LogicalRewriteWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/LogicalRewriteWrite 
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 = 'IO'
  AND wait_event = 'LogicalRewriteWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalRewriteWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.43 - IO: LogicalSubxactRead

Waiting for a read from a logical subxact file.
PostgreSQL wait event dossier
ClassIO EventLogicalSubxactRead VersionsPG 14 Evidence1 source location(s)

Official description

Waiting for a read from a logical subxact file.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ — — — —

Trigger mechanism

The catalog identity is present, but source audit found no live reporter in 14. Known active ranges: none. The definition location below is retained as negative evidence; this exact release cannot emit the event from a core code path. Evidence: pgsql-hackers confirmation.

Normal or trouble?

  • Normal: No live core occurrence is expected on the audited release.
  • Investigate: If telemetry shows it, verify the exact patch version, extension origin, and whether the sample is stale or came from a different server.

Diagnostic SQL

Sessions waiting on IO/LogicalSubxactRead 
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 = 'IO'
  AND wait_event = 'LogicalSubxactRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalSubxactRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.44 - IO: LogicalSubxactWrite

Waiting for a write to a logical subxact file.
PostgreSQL wait event dossier
ClassIO EventLogicalSubxactWrite VersionsPG 14 Evidence1 source location(s)

Official description

Waiting for a write to a logical subxact file.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ — — — —

Trigger mechanism

The catalog identity is present, but source audit found no live reporter in 14. Known active ranges: none. The definition location below is retained as negative evidence; this exact release cannot emit the event from a core code path. Evidence: pgsql-hackers confirmation.

Normal or trouble?

  • Normal: No live core occurrence is expected on the audited release.
  • Investigate: If telemetry shows it, verify the exact patch version, extension origin, and whether the sample is stale or came from a different server.

Diagnostic SQL

Sessions waiting on IO/LogicalSubxactWrite 
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 = 'IO'
  AND wait_event = 'LogicalSubxactWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'LogicalSubxactWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.45 - IO: RelationMapRead

Waiting for a read of the relation map file
PostgreSQL wait event dossier
ClassIO EventRelationMapRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read of the relation map file

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

Trigger mechanism

WAIT_EVENT_RELATION_MAP_READ at src/backend/utils/cache/relmapper.c:822 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:236. The instrumented operation is: Waiting for a read of the relation map file. PostgreSQL reports RelationMapRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/RelationMapRead 
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 = 'IO'
  AND wait_event = 'RelationMapRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'RelationMapRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.46 - IO: RelationMapReplace

Waiting for durable replacement of a relation map file
PostgreSQL wait event dossier
ClassIO EventRelationMapReplace VersionsPG 16-18 Evidence2 source location(s)

Official description

Waiting for durable replacement of a relation map file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_RELATION_MAP_REPLACE at src/backend/utils/cache/relmapper.c:988 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:237. The instrumented operation is: Waiting for durable replacement of a relation map file. PostgreSQL reports RelationMapReplace around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/RelationMapReplace 
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 = 'IO'
  AND wait_event = 'RelationMapReplace'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'RelationMapReplace'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.47 - IO: RelationMapSync

Waiting for the relation map file to reach durable storage.
PostgreSQL wait event dossier
ClassIO EventRelationMapSync VersionsPG 13-15 Evidence2 source location(s)

Official description

Waiting for the relation map file to reach durable storage.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ — — —

Trigger mechanism

WAIT_EVENT_RELATION_MAP_SYNC at src/backend/utils/cache/relmapper.c:957 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:637. The instrumented operation is: Waiting for the relation map file to reach durable storage. PostgreSQL reports RelationMapSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/RelationMapSync 
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 = 'IO'
  AND wait_event = 'RelationMapSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'RelationMapSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.48 - IO: RelationMapWrite

Waiting for a write to the relation map file
PostgreSQL wait event dossier
ClassIO EventRelationMapWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write to the relation map file

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

Trigger mechanism

WAIT_EVENT_RELATION_MAP_WRITE at src/backend/utils/cache/relmapper.c:939 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:238. The instrumented operation is: Waiting for a write to the relation map file. PostgreSQL reports RelationMapWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/RelationMapWrite 
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 = 'IO'
  AND wait_event = 'RelationMapWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'RelationMapWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.49 - IO: ReorderBufferRead

Waiting for a read during reorder buffer management
PostgreSQL wait event dossier
ClassIO EventReorderBufferRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read during reorder buffer management

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

Trigger mechanism

WAIT_EVENT_REORDER_BUFFER_READ at src/backend/replication/logical/reorderbuffer.c:4609 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:239. The instrumented operation is: Waiting for a read during reorder buffer management. PostgreSQL reports ReorderBufferRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReorderBufferRead 
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 = 'IO'
  AND wait_event = 'ReorderBufferRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReorderBufferRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.50 - IO: ReorderBufferWrite

Waiting for a write during reorder buffer management
PostgreSQL wait event dossier
ClassIO EventReorderBufferWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write during reorder buffer management

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

Trigger mechanism

WAIT_EVENT_REORDER_BUFFER_WRITE at src/backend/replication/logical/reorderbuffer.c:4265 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:240. The instrumented operation is: Waiting for a write during reorder buffer management. PostgreSQL reports ReorderBufferWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReorderBufferWrite 
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 = 'IO'
  AND wait_event = 'ReorderBufferWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReorderBufferWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.51 - IO: ReorderLogicalMappingRead

Waiting for a read of a logical mapping during reorder buffer management
PostgreSQL wait event dossier
ClassIO EventReorderLogicalMappingRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read of a logical mapping during reorder buffer management

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

Trigger mechanism

WAIT_EVENT_REORDER_LOGICAL_MAPPING_READ at src/backend/replication/logical/reorderbuffer.c:5383 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:241. The instrumented operation is: Waiting for a read of a logical mapping during reorder buffer management. PostgreSQL reports ReorderLogicalMappingRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReorderLogicalMappingRead 
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 = 'IO'
  AND wait_event = 'ReorderLogicalMappingRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReorderLogicalMappingRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.52 - IO: ReplicationSlotRead

Waiting for a read from a replication slot control file
PostgreSQL wait event dossier
ClassIO EventReplicationSlotRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read from a replication slot control file

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

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOT_READ at src/backend/replication/slot.c:2540 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:242. The instrumented operation is: Waiting for a read from a replication slot control file. PostgreSQL reports ReplicationSlotRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReplicationSlotRead 
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 = 'IO'
  AND wait_event = 'ReplicationSlotRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReplicationSlotRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.53 - IO: ReplicationSlotRestoreSync

Waiting for a replication slot control file to reach durable storage while restoring it to memory
PostgreSQL wait event dossier
ClassIO EventReplicationSlotRestoreSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a replication slot control file to reach durable storage while restoring it to memory

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

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOT_RESTORE_SYNC at src/backend/replication/slot.c:2526 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:243. The instrumented operation is: Waiting for a replication slot control file to reach durable storage while restoring it to memory. PostgreSQL reports ReplicationSlotRestoreSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReplicationSlotRestoreSync 
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 = 'IO'
  AND wait_event = 'ReplicationSlotRestoreSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReplicationSlotRestoreSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.54 - IO: ReplicationSlotSync

Waiting for a replication slot control file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventReplicationSlotSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a replication slot control file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOT_SYNC at src/backend/replication/slot.c:2405 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:244. The instrumented operation is: Waiting for a replication slot control file to reach durable storage. PostgreSQL reports ReplicationSlotSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReplicationSlotSync 
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 = 'IO'
  AND wait_event = 'ReplicationSlotSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReplicationSlotSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.55 - IO: ReplicationSlotWrite

Waiting for a write to a replication slot control file
PostgreSQL wait event dossier
ClassIO EventReplicationSlotWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write to a replication slot control file

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

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOT_WRITE at src/backend/replication/slot.c:2384 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:245. The instrumented operation is: Waiting for a write to a replication slot control file. PostgreSQL reports ReplicationSlotWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/ReplicationSlotWrite 
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 = 'IO'
  AND wait_event = 'ReplicationSlotWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ReplicationSlotWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.56 - IO: SlruFlushSync

Waiting for SLRU data to reach durable storage during a checkpoint or database shutdown
PostgreSQL wait event dossier
ClassIO EventSlruFlushSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for SLRU data to reach durable storage during a checkpoint or database shutdown

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/SLRUFlushSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_SLRU_FLUSH_SYNC at src/backend/access/transam/slru.c:1606 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:679. The instrumented operation is: Waiting for SLRU data to reach durable storage during a checkpoint or database shutdown. PostgreSQL reports SlruFlushSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SlruFlushSync 
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 = 'IO'
  AND wait_event = 'SlruFlushSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SlruFlushSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.57 - IO: SlruRead

Waiting for a read of an SLRU page
PostgreSQL wait event dossier
ClassIO EventSlruRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read of an SLRU page

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/SLRURead (PG 13-16)

Trigger mechanism

WAIT_EVENT_SLRU_READ at src/backend/access/transam/slru.c:721 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:682. The instrumented operation is: Waiting for a read of an SLRU page. PostgreSQL reports SlruRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SlruRead 
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 = 'IO'
  AND wait_event = 'SlruRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SlruRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.58 - IO: SlruSync

Waiting for SLRU data to reach durable storage following a page write
PostgreSQL wait event dossier
ClassIO EventSlruSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for SLRU data to reach durable storage following a page write

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/SLRUSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_SLRU_SYNC at src/backend/access/transam/slru.c:900 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:685. The instrumented operation is: Waiting for SLRU data to reach durable storage following a page write. PostgreSQL reports SlruSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SlruSync 
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 = 'IO'
  AND wait_event = 'SlruSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SlruSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.59 - IO: SlruWrite

Waiting for a write of an SLRU page
PostgreSQL wait event dossier
ClassIO EventSlruWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write of an SLRU page

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/SLRUWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_SLRU_WRITE at src/backend/access/transam/slru.c:876 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:688. The instrumented operation is: Waiting for a write of an SLRU page. PostgreSQL reports SlruWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SlruWrite 
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 = 'IO'
  AND wait_event = 'SlruWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SlruWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.60 - IO: SnapbuildRead

Waiting for a read of a serialized historical catalog snapshot
PostgreSQL wait event dossier
ClassIO EventSnapbuildRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read of a serialized historical catalog snapshot

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

Trigger mechanism

WAIT_EVENT_SNAPBUILD_READ at src/backend/replication/logical/snapbuild.c:1937 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:250. The instrumented operation is: Waiting for a read of a serialized historical catalog snapshot. PostgreSQL reports SnapbuildRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SnapbuildRead 
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 = 'IO'
  AND wait_event = 'SnapbuildRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SnapbuildRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.61 - IO: SnapbuildSync

Waiting for a serialized historical catalog snapshot to reach durable storage
PostgreSQL wait event dossier
ClassIO EventSnapbuildSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a serialized historical catalog snapshot to reach durable storage

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

Trigger mechanism

WAIT_EVENT_SNAPBUILD_SYNC at src/backend/replication/logical/snapbuild.c:1680 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:251. The instrumented operation is: Waiting for a serialized historical catalog snapshot to reach durable storage. PostgreSQL reports SnapbuildSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SnapbuildSync 
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 = 'IO'
  AND wait_event = 'SnapbuildSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SnapbuildSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.62 - IO: SnapbuildWrite

Waiting for a write of a serialized historical catalog snapshot
PostgreSQL wait event dossier
ClassIO EventSnapbuildWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of a serialized historical catalog snapshot

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

Trigger mechanism

WAIT_EVENT_SNAPBUILD_WRITE at src/backend/replication/logical/snapbuild.c:1654 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:252. The instrumented operation is: Waiting for a write of a serialized historical catalog snapshot. PostgreSQL reports SnapbuildWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/SnapbuildWrite 
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 = 'IO'
  AND wait_event = 'SnapbuildWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'SnapbuildWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.63 - IO: TimelineHistoryFileSync

Waiting for a timeline history file received via streaming replication to reach durable storage
PostgreSQL wait event dossier
ClassIO EventTimelineHistoryFileSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a timeline history file received via streaming replication to reach durable storage

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

Trigger mechanism

WAIT_EVENT_TIMELINE_HISTORY_FILE_SYNC at src/backend/access/transam/timeline.c:502 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:253. The instrumented operation is: Waiting for a timeline history file received via streaming replication to reach durable storage. PostgreSQL reports TimelineHistoryFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TimelineHistoryFileSync 
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 = 'IO'
  AND wait_event = 'TimelineHistoryFileSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TimelineHistoryFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.64 - IO: TimelineHistoryFileWrite

Waiting for a write of a timeline history file received via streaming replication
PostgreSQL wait event dossier
ClassIO EventTimelineHistoryFileWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of a timeline history file received via streaming replication

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

Trigger mechanism

WAIT_EVENT_TIMELINE_HISTORY_FILE_WRITE at src/backend/access/transam/timeline.c:484 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:254. The instrumented operation is: Waiting for a write of a timeline history file received via streaming replication. PostgreSQL reports TimelineHistoryFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TimelineHistoryFileWrite 
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 = 'IO'
  AND wait_event = 'TimelineHistoryFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TimelineHistoryFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.65 - IO: TimelineHistoryRead

Waiting for a read of a timeline history file
PostgreSQL wait event dossier
ClassIO EventTimelineHistoryRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read of a timeline history file

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

Trigger mechanism

WAIT_EVENT_TIMELINE_HISTORY_READ at src/backend/access/transam/timeline.c:135 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:255. The instrumented operation is: Waiting for a read of a timeline history file. PostgreSQL reports TimelineHistoryRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TimelineHistoryRead 
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 = 'IO'
  AND wait_event = 'TimelineHistoryRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TimelineHistoryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.66 - IO: TimelineHistorySync

Waiting for a newly created timeline history file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventTimelineHistorySync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a newly created timeline history file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_TIMELINE_HISTORY_SYNC at src/backend/access/transam/timeline.c:428 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:256. The instrumented operation is: Waiting for a newly created timeline history file to reach durable storage. PostgreSQL reports TimelineHistorySync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TimelineHistorySync 
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 = 'IO'
  AND wait_event = 'TimelineHistorySync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TimelineHistorySync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.67 - IO: TimelineHistoryWrite

Waiting for a write of a newly created timeline history file
PostgreSQL wait event dossier
ClassIO EventTimelineHistoryWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of a newly created timeline history file

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

Trigger mechanism

WAIT_EVENT_TIMELINE_HISTORY_WRITE at src/backend/access/transam/timeline.c:366 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:257. The instrumented operation is: Waiting for a write of a newly created timeline history file. PostgreSQL reports TimelineHistoryWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TimelineHistoryWrite 
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 = 'IO'
  AND wait_event = 'TimelineHistoryWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TimelineHistoryWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.68 - IO: TwophaseFileRead

Waiting for a read of a two phase state file
PostgreSQL wait event dossier
ClassIO EventTwophaseFileRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a read of a two phase state file

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

Trigger mechanism

WAIT_EVENT_TWOPHASE_FILE_READ at src/backend/access/transam/twophase.c:1347 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:258. The instrumented operation is: Waiting for a read of a two phase state file. PostgreSQL reports TwophaseFileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TwophaseFileRead 
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 = 'IO'
  AND wait_event = 'TwophaseFileRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TwophaseFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.69 - IO: TwophaseFileSync

Waiting for a two phase state file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventTwophaseFileSync VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a two phase state file to reach durable storage

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

Trigger mechanism

WAIT_EVENT_TWOPHASE_FILE_SYNC at src/backend/access/transam/twophase.c:1774 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:259. The instrumented operation is: Waiting for a two phase state file to reach durable storage. PostgreSQL reports TwophaseFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TwophaseFileSync 
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 = 'IO'
  AND wait_event = 'TwophaseFileSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TwophaseFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.70 - IO: TwophaseFileWrite

Waiting for a write of a two phase state file
PostgreSQL wait event dossier
ClassIO EventTwophaseFileWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a write of a two phase state file

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

Trigger mechanism

WAIT_EVENT_TWOPHASE_FILE_WRITE at src/backend/access/transam/twophase.c:1749 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:260. The instrumented operation is: Waiting for a write of a two phase state file. PostgreSQL reports TwophaseFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/TwophaseFileWrite 
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 = 'IO'
  AND wait_event = 'TwophaseFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'TwophaseFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.71 - IO: VersionFileSync

Waiting for the version file to reach durable storage while creating a database
PostgreSQL wait event dossier
ClassIO EventVersionFileSync VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for the version file to reach durable storage while creating a database

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_VERSION_FILE_SYNC at src/backend/commands/dbcommands.c:511 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:261. The instrumented operation is: Waiting for the version file to reach durable storage while creating a database. PostgreSQL reports VersionFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/VersionFileSync 
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 = 'IO'
  AND wait_event = 'VersionFileSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'VersionFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.72 - IO: VersionFileWrite

Waiting for the version file to be written while creating a database
PostgreSQL wait event dossier
ClassIO EventVersionFileWrite VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for the version file to be written while creating a database

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_VERSION_FILE_WRITE at src/backend/commands/dbcommands.c:498 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:262. The instrumented operation is: Waiting for the version file to be written while creating a database. PostgreSQL reports VersionFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/VersionFileWrite 
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 = 'IO'
  AND wait_event = 'VersionFileWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'VersionFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.73 - IO: WalBootstrapSync

Waiting for WAL to reach durable storage during bootstrapping
PostgreSQL wait event dossier
ClassIO EventWalBootstrapSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for WAL to reach durable storage during bootstrapping

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALBootstrapSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_BOOTSTRAP_SYNC at src/backend/access/transam/xlog.c:4776 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:733. The instrumented operation is: Waiting for WAL to reach durable storage during bootstrapping. PostgreSQL reports WalBootstrapSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalBootstrapSync 
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 = 'IO'
  AND wait_event = 'WalBootstrapSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalBootstrapSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.74 - IO: WalBootstrapWrite

Waiting for a write of a WAL page during bootstrapping
PostgreSQL wait event dossier
ClassIO EventWalBootstrapWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write of a WAL page during bootstrapping

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALBootstrapWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_BOOTSTRAP_WRITE at src/backend/access/transam/xlog.c:4764 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:736. The instrumented operation is: Waiting for a write of a WAL page during bootstrapping. PostgreSQL reports WalBootstrapWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalBootstrapWrite 
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 = 'IO'
  AND wait_event = 'WalBootstrapWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalBootstrapWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.75 - IO: WalCopyRead

Waiting for a read when creating a new WAL segment by copying an existing one
PostgreSQL wait event dossier
ClassIO EventWalCopyRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read when creating a new WAL segment by copying an existing one

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALCopyRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_COPY_READ at src/backend/access/transam/xlog.c:3190 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:739. The instrumented operation is: Waiting for a read when creating a new WAL segment by copying an existing one. PostgreSQL reports WalCopyRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalCopyRead 
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 = 'IO'
  AND wait_event = 'WalCopyRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalCopyRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.76 - IO: WalCopySync

Waiting for a new WAL segment created by copying an existing one to reach durable storage
PostgreSQL wait event dossier
ClassIO EventWalCopySync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a new WAL segment created by copying an existing one to reach durable storage

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALCopySync (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_COPY_SYNC at src/backend/access/transam/xlog.c:3227 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:742. The instrumented operation is: Waiting for a new WAL segment created by copying an existing one to reach durable storage. PostgreSQL reports WalCopySync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalCopySync 
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 = 'IO'
  AND wait_event = 'WalCopySync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalCopySync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.77 - IO: WalCopyWrite

Waiting for a write when creating a new WAL segment by copying an existing one
PostgreSQL wait event dossier
ClassIO EventWalCopyWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write when creating a new WAL segment by copying an existing one

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALCopyWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_COPY_WRITE at src/backend/access/transam/xlog.c:3208 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:745. The instrumented operation is: Waiting for a write when creating a new WAL segment by copying an existing one. PostgreSQL reports WalCopyWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalCopyWrite 
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 = 'IO'
  AND wait_event = 'WalCopyWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalCopyWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.78 - IO: WalInitSync

Waiting for a newly initialized WAL file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventWalInitSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a newly initialized WAL file to reach durable storage

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALInitSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_INIT_SYNC at src/backend/access/transam/xlog.c:3028 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:748. The instrumented operation is: Waiting for a newly initialized WAL file to reach durable storage. PostgreSQL reports WalInitSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalInitSync 
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 = 'IO'
  AND wait_event = 'WalInitSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalInitSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.79 - IO: WalInitWrite

Waiting for a write while initializing a new WAL file
PostgreSQL wait event dossier
ClassIO EventWalInitWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write while initializing a new WAL file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALInitWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_INIT_WRITE at src/backend/access/transam/xlog.c:2977 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:751. The instrumented operation is: Waiting for a write while initializing a new WAL file. PostgreSQL reports WalInitWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalInitWrite 
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 = 'IO'
  AND wait_event = 'WalInitWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalInitWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.80 - IO: WalRead

Waiting for a read from a WAL file
PostgreSQL wait event dossier
ClassIO EventWalRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read from a WAL file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_READ at src/backend/access/transam/xlogreader.c:1570 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:754. The instrumented operation is: Waiting for a read from a WAL file. PostgreSQL reports WalRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalRead 
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 = 'IO'
  AND wait_event = 'WalRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.81 - IO: WalSummaryRead

Waiting for a read from a WAL summary file
PostgreSQL wait event dossier
ClassIO EventWalSummaryRead VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for a read from a WAL summary file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_SUMMARY_READ at src/backend/backup/walsummary.c:279 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:272. The instrumented operation is: Waiting for a read from a WAL summary file. PostgreSQL reports WalSummaryRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalSummaryRead 
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 = 'IO'
  AND wait_event = 'WalSummaryRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalSummaryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.82 - IO: WalSummaryWrite

Waiting for a write to a WAL summary file
PostgreSQL wait event dossier
ClassIO EventWalSummaryWrite VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for a write to a WAL summary file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_SUMMARY_WRITE at src/backend/backup/walsummary.c:300 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:273. The instrumented operation is: Waiting for a write to a WAL summary file. PostgreSQL reports WalSummaryWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalSummaryWrite 
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 = 'IO'
  AND wait_event = 'WalSummaryWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalSummaryWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.83 - IO: WalSync

Waiting for a WAL file to reach durable storage
PostgreSQL wait event dossier
ClassIO EventWalSync VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a WAL file to reach durable storage

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALSync (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_SYNC at src/backend/access/transam/xlog.c:8303 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:757. The instrumented operation is: Waiting for a WAL file to reach durable storage. PostgreSQL reports WalSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalSync 
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 = 'IO'
  AND wait_event = 'WalSync'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.84 - IO: WalSyncMethodAssign

Waiting for data to reach durable storage while assigning a new WAL sync method
PostgreSQL wait event dossier
ClassIO EventWalSyncMethodAssign VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for data to reach durable storage while assigning a new WAL sync method

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALSyncMethodAssign (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_SYNC_METHOD_ASSIGN at src/backend/access/transam/xlog.c:8251 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:760. The instrumented operation is: Waiting for data to reach durable storage while assigning a new WAL sync method. PostgreSQL reports WalSyncMethodAssign around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalSyncMethodAssign 
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 = 'IO'
  AND wait_event = 'WalSyncMethodAssign'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalSyncMethodAssign'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.85 - IO: WalWrite

Waiting for a write to a WAL file
PostgreSQL wait event dossier
ClassIO EventWalWrite VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a write to a WAL file

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_WRITE at src/backend/access/transam/xlog.c:2200 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:763. The instrumented operation is: Waiting for a write to a WAL file. PostgreSQL reports WalWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalWrite 
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 = 'IO'
  AND wait_event = 'WalWrite'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

6.86 - IO: WalsenderTimelineHistoryRead

Waiting for a read from a timeline history file during a walsender timeline command
PostgreSQL wait event dossier
ClassIO EventWalsenderTimelineHistoryRead VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for a read from a timeline history file during a walsender timeline command

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IO/WALSenderTimelineHistoryRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_WALSENDER_TIMELINE_HISTORY_READ at src/backend/replication/walsender.c:654 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:730. The instrumented operation is: Waiting for a read from a timeline history file during a walsender timeline command. PostgreSQL reports WalsenderTimelineHistoryRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

  • Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
  • Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

Diagnostic SQL

Sessions waiting on IO/WalsenderTimelineHistoryRead 
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 = 'IO'
  AND wait_event = 'WalsenderTimelineHistoryRead'
ORDER BY query_age DESC NULLS LAST;
Current IO 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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'WalsenderTimelineHistoryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Confirm the workload phase should touch this file class.
  2. Correlate with pg_stat_io where available and per-device latency.
  3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

Related controls and signals

7 - IPC waits

PostgreSQL processes waiting for peers, workers, barriers, queues, or phase changes.

IPC is coordination: this process has reached a point that depends on another PostgreSQL process or execution participant. The peer may be a parallel worker, WAL receiver, checkpointer, archiver, replication process, or another backend in a shared-memory protocol.

Find the missing peer or phase

The waiter is often healthy. Ask which participant is expected to signal it and inspect that participant’s state. Parallel-query events should be read as a phase diagram; replication events as a sender/receiver pipeline; checkpoint events as a cluster-wide barrier.

  • Normal: brief rendezvous in parallel plans, checkpoint start/completion, worker startup, or synchronous replication.
  • Watch: a foreground waiter remains in the same phase across three samples while its peer makes no visible progress.
  • Urgent: the peer has exited or is blocked, a queue cannot drain, replication/failover is stalled, or many sessions depend on one stuck coordinator.

Events to recognize

Event Peer or phase
BufferIo Another backend performing I/O for the shared buffer
ExecuteGather Child processes feeding a Gather node
ParallelFinish Parallel workers reaching plan completion
CheckpointDone Checkpointer completing a requested checkpoint
SyncRep Remote synchronous standby acknowledgement
WalReceiverWaitStart Startup process waiting for streaming data
MessageQueueReceive Shared-memory message queue producer
RecoveryPause Recovery intentionally paused by operator policy

Common misreads

  • Killing the waiter does not repair a dead or blocked peer.
  • IPC/SyncRep is acknowledgement latency; LWLock/SyncRep is contention on shared queue/state metadata.
  • Many parallel wait names are expected barriers. The question is whether every participant eventually advances.
  • RecoveryPause can be entirely intentional; check pg_is_wal_replay_paused() before treating it as failure.

7.1 - IPC: AppendReady

Waiting for subplan nodes of an Append plan node to be ready
PostgreSQL wait event dossier
ClassIPC EventAppendReady VersionsPG 14-18 Evidence2 source location(s)

Official description

Waiting for subplan nodes of an Append plan node to be ready

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_APPEND_READY at src/backend/executor/nodeAppend.c:1079 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:106. The instrumented operation is: Waiting for subplan nodes of an Append plan node to be ready. The AppendReady path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/AppendReady 
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 = 'IPC'
  AND wait_event = 'AppendReady'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'AppendReady'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.2 - IPC: ArchiveCleanupCommand

Waiting for archive_cleanup_command to complete
PostgreSQL wait event dossier
ClassIPC EventArchiveCleanupCommand VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for archive_cleanup_command to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_ARCHIVE_CLEANUP_COMMAND at src/backend/access/transam/xlog.c:7885 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:107. The instrumented operation is: Waiting for archive_cleanup_command to complete. The ArchiveCleanupCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ArchiveCleanupCommand 
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 = 'IPC'
  AND wait_event = 'ArchiveCleanupCommand'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ArchiveCleanupCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.3 - IPC: ArchiveCommand

Waiting for archive_command to complete
PostgreSQL wait event dossier
ClassIPC EventArchiveCommand VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for archive_command to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_ARCHIVE_COMMAND at src/backend/archive/shell_archive.c:79 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:108. The instrumented operation is: Waiting for archive_command to complete. The ArchiveCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ArchiveCommand 
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 = 'IPC'
  AND wait_event = 'ArchiveCommand'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ArchiveCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.4 - IPC: BackendTermination

Waiting for the termination of another backend
PostgreSQL wait event dossier
ClassIPC EventBackendTermination VersionsPG 14-18 Evidence2 source location(s)

Official description

Waiting for the termination of another backend

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_BACKEND_TERMINATION at src/backend/storage/ipc/signalfuncs.c:210 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:109. The instrumented operation is: Waiting for the termination of another backend. The BackendTermination path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BackendTermination 
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 = 'IPC'
  AND wait_event = 'BackendTermination'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BackendTermination'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.5 - IPC: BackupWaitWalArchive

Waiting for WAL files required for a backup to be successfully archived
PostgreSQL wait event dossier
ClassIPC EventBackupWaitWalArchive VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for WAL files required for a backup to be successfully archived

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

Trigger mechanism

WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE at src/backend/access/transam/xlog.c:9405 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:110. The instrumented operation is: Waiting for WAL files required for a backup to be successfully archived. The BackupWaitWalArchive path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BackupWaitWalArchive 
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 = 'IPC'
  AND wait_event = 'BackupWaitWalArchive'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BackupWaitWalArchive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.6 - IPC: BgworkerShutdown

Waiting for background worker to shut down
PostgreSQL wait event dossier
ClassIPC EventBgworkerShutdown VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for background worker to shut down

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IPC/BgWorkerShutdown (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWORKER_SHUTDOWN at src/backend/postmaster/bgworker.c:1188 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:329. The instrumented operation is: Waiting for background worker to shut down. The BgworkerShutdown path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BgworkerShutdown 
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 = 'IPC'
  AND wait_event = 'BgworkerShutdown'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BgworkerShutdown'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.7 - IPC: BgworkerStartup

Waiting for background worker to start up
PostgreSQL wait event dossier
ClassIPC EventBgworkerStartup VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for background worker to start up

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IPC/BgWorkerStartup (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWORKER_STARTUP at src/backend/access/transam/parallel.c:771 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:332. The instrumented operation is: Waiting for background worker to start up. The BgworkerStartup path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BgworkerStartup 
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 = 'IPC'
  AND wait_event = 'BgworkerStartup'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BgworkerStartup'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.8 - IPC: BtreePage

Waiting for the page number needed to continue a parallel B-tree scan to become available
PostgreSQL wait event dossier
ClassIPC EventBtreePage VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for the page number needed to continue a parallel B-tree scan to become available

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

Trigger mechanism

WAIT_EVENT_BTREE_PAGE at src/backend/access/nbtree/nbtree.c:927 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:113. The instrumented operation is: Waiting for the page number needed to continue a parallel B-tree scan to become available. The BtreePage path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BtreePage 
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 = 'IPC'
  AND wait_event = 'BtreePage'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BtreePage'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.9 - IPC: BufferIo

Waiting for buffer I/O to complete
PostgreSQL wait event dossier
ClassIPC EventBufferIo VersionsPG 17-18 Evidence7 source location(s)

Official description

Waiting for buffer I/O to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IPC/BufferIO (PG 14-16), LWLock/BufferIO (PG 13)

Trigger mechanism

pgstat_report_wait_start at src/backend/storage/lmgr/lwlock.c:765 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/access/transam/xact.c:2627. The instrumented operation is: Waiting for buffer I/O to complete. The BufferIo path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/BufferIo 
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 = 'IPC'
  AND wait_event = 'BufferIo'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'BufferIo'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.10 - IPC: CheckpointDelayComplete

Waiting for a backend that blocks a checkpoint from completing
PostgreSQL wait event dossier
ClassIPC EventCheckpointDelayComplete VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for a backend that blocks a checkpoint from completing

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DELAY_COMPLETE at src/backend/access/transam/xlog.c:7228 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:115. The instrumented operation is: Waiting for a backend that blocks a checkpoint from completing. The CheckpointDelayComplete path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/CheckpointDelayComplete 
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 = 'IPC'
  AND wait_event = 'CheckpointDelayComplete'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'CheckpointDelayComplete'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.11 - IPC: CheckpointDelayStart

Waiting for a backend that blocks a checkpoint from starting
PostgreSQL wait event dossier
ClassIPC EventCheckpointDelayStart VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for a backend that blocks a checkpoint from starting

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DELAY_START at src/backend/access/transam/xlog.c:7211 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:116. The instrumented operation is: Waiting for a backend that blocks a checkpoint from starting. The CheckpointDelayStart path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/CheckpointDelayStart 
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 = 'IPC'
  AND wait_event = 'CheckpointDelayStart'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'CheckpointDelayStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.12 - IPC: CheckpointDone

Waiting for a checkpoint to complete
PostgreSQL wait event dossier
ClassIPC EventCheckpointDone VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a checkpoint to complete

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

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DONE at src/backend/postmaster/checkpointer.c:1121 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:117. The instrumented operation is: Waiting for a checkpoint to complete. The CheckpointDone path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/CheckpointDone 
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 = 'IPC'
  AND wait_event = 'CheckpointDone'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'CheckpointDone'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.13 - IPC: CheckpointStart

Waiting for a checkpoint to start
PostgreSQL wait event dossier
ClassIPC EventCheckpointStart VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a checkpoint to start

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

Trigger mechanism

WAIT_EVENT_CHECKPOINT_START at src/backend/postmaster/checkpointer.c:1100 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:118. The instrumented operation is: Waiting for a checkpoint to start. The CheckpointStart path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/CheckpointStart 
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 = 'IPC'
  AND wait_event = 'CheckpointStart'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'CheckpointStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.14 - IPC: ExecuteGather

Waiting for activity from a child process while executing a Gather plan node
PostgreSQL wait event dossier
ClassIPC EventExecuteGather VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for activity from a child process while executing a Gather plan node

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

Trigger mechanism

WAIT_EVENT_EXECUTE_GATHER at src/backend/executor/nodeGather.c:386 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:119. The instrumented operation is: Waiting for activity from a child process while executing a Gather plan node. The ExecuteGather path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ExecuteGather 
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 = 'IPC'
  AND wait_event = 'ExecuteGather'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ExecuteGather'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.15 - IPC: HashBatchAllocate

Waiting for an elected Parallel Hash participant to allocate a hash table
PostgreSQL wait event dossier
ClassIPC EventHashBatchAllocate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an elected Parallel Hash participant to allocate a hash table

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

Trigger mechanism

WAIT_EVENT_HASH_BATCH_ALLOCATE at src/backend/executor/nodeHashjoin.c:1321 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:120. The instrumented operation is: Waiting for an elected Parallel Hash participant to allocate a hash table. The HashBatchAllocate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBatchAllocate 
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 = 'IPC'
  AND wait_event = 'HashBatchAllocate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBatchAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.16 - IPC: HashBatchElect

Waiting to elect a Parallel Hash participant to allocate a hash table
PostgreSQL wait event dossier
ClassIPC EventHashBatchElect VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to elect a Parallel Hash participant to allocate a hash table

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

Trigger mechanism

WAIT_EVENT_HASH_BATCH_ELECT at src/backend/executor/nodeHashjoin.c:1314 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:121. The instrumented operation is: Waiting to elect a Parallel Hash participant to allocate a hash table. The HashBatchElect path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBatchElect 
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 = 'IPC'
  AND wait_event = 'HashBatchElect'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBatchElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.17 - IPC: HashBatchLoad

Waiting for other Parallel Hash participants to finish loading a hash table
PostgreSQL wait event dossier
ClassIPC EventHashBatchLoad VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for other Parallel Hash participants to finish loading a hash table

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

Trigger mechanism

WAIT_EVENT_HASH_BATCH_LOAD at src/backend/executor/nodeHashjoin.c:1341 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:122. The instrumented operation is: Waiting for other Parallel Hash participants to finish loading a hash table. The HashBatchLoad path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBatchLoad 
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 = 'IPC'
  AND wait_event = 'HashBatchLoad'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBatchLoad'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.18 - IPC: HashBuildAllocate

Waiting for an elected Parallel Hash participant to allocate the initial hash table
PostgreSQL wait event dossier
ClassIPC EventHashBuildAllocate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an elected Parallel Hash participant to allocate the initial hash table

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

Trigger mechanism

WAIT_EVENT_HASH_BUILD_ALLOCATE at src/backend/executor/nodeHash.c:261 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:123. The instrumented operation is: Waiting for an elected Parallel Hash participant to allocate the initial hash table. The HashBuildAllocate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBuildAllocate 
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 = 'IPC'
  AND wait_event = 'HashBuildAllocate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBuildAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.19 - IPC: HashBuildElect

Waiting to elect a Parallel Hash participant to allocate the initial hash table
PostgreSQL wait event dossier
ClassIPC EventHashBuildElect VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to elect a Parallel Hash participant to allocate the initial hash table

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

Trigger mechanism

WAIT_EVENT_HASH_BUILD_ELECT at src/backend/executor/nodeHash.c:598 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:124. The instrumented operation is: Waiting to elect a Parallel Hash participant to allocate the initial hash table. The HashBuildElect path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBuildElect 
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 = 'IPC'
  AND wait_event = 'HashBuildElect'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBuildElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.20 - IPC: HashBuildHashInner

Waiting for other Parallel Hash participants to finish hashing the inner relation
PostgreSQL wait event dossier
ClassIPC EventHashBuildHashInner VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for other Parallel Hash participants to finish hashing the inner relation

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

Trigger mechanism

WAIT_EVENT_HASH_BUILD_HASH_INNER at src/backend/executor/nodeHash.c:324 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:125. The instrumented operation is: Waiting for other Parallel Hash participants to finish hashing the inner relation. The HashBuildHashInner path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBuildHashInner 
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 = 'IPC'
  AND wait_event = 'HashBuildHashInner'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBuildHashInner'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.21 - IPC: HashBuildHashOuter

Waiting for other Parallel Hash participants to finish partitioning the outer relation
PostgreSQL wait event dossier
ClassIPC EventHashBuildHashOuter VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for other Parallel Hash participants to finish partitioning the outer relation

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

Trigger mechanism

WAIT_EVENT_HASH_BUILD_HASH_OUTER at src/backend/executor/nodeHashjoin.c:397 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:126. The instrumented operation is: Waiting for other Parallel Hash participants to finish partitioning the outer relation. The HashBuildHashOuter path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashBuildHashOuter 
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 = 'IPC'
  AND wait_event = 'HashBuildHashOuter'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashBuildHashOuter'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.22 - IPC: HashGrowBatchesDecide

Waiting to elect a Parallel Hash participant to decide on future batch growth
PostgreSQL wait event dossier
ClassIPC EventHashGrowBatchesDecide VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to elect a Parallel Hash participant to decide on future batch growth

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BATCHES_DECIDE at src/backend/executor/nodeHash.c:1363 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:127. The instrumented operation is: Waiting to elect a Parallel Hash participant to decide on future batch growth. The HashGrowBatchesDecide path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBatchesDecide 
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 = 'IPC'
  AND wait_event = 'HashGrowBatchesDecide'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBatchesDecide'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.23 - IPC: HashGrowBatchesElect

Waiting to elect a Parallel Hash participant to allocate more batches
PostgreSQL wait event dossier
ClassIPC EventHashGrowBatchesElect VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to elect a Parallel Hash participant to allocate more batches

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BATCHES_ELECT at src/backend/executor/nodeHash.c:1220 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:128. The instrumented operation is: Waiting to elect a Parallel Hash participant to allocate more batches. The HashGrowBatchesElect path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBatchesElect 
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 = 'IPC'
  AND wait_event = 'HashGrowBatchesElect'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBatchesElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.24 - IPC: HashGrowBatchesFinish

Waiting for an elected Parallel Hash participant to decide on future batch growth
PostgreSQL wait event dossier
ClassIPC EventHashGrowBatchesFinish VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for an elected Parallel Hash participant to decide on future batch growth

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BATCHES_FINISH at src/backend/executor/nodeHash.c:1420 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:129. The instrumented operation is: Waiting for an elected Parallel Hash participant to decide on future batch growth. The HashGrowBatchesFinish path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBatchesFinish 
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 = 'IPC'
  AND wait_event = 'HashGrowBatchesFinish'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBatchesFinish'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.25 - IPC: HashGrowBatchesReallocate

Waiting for an elected Parallel Hash participant to allocate more batches
PostgreSQL wait event dossier
ClassIPC EventHashGrowBatchesReallocate VersionsPG 16-18 Evidence4 source location(s)

Official description

Waiting for an elected Parallel Hash participant to allocate more batches

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Earlier names: IPC/HashGrowBatchesAllocate (PG 13-15)

Trigger mechanism

WAIT_EVENT_HASH_GROW_BATCHES_ALLOCATE at src/backend/executor/nodeHash.c:1229 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:368. The instrumented operation is: Waiting for an elected Parallel Hash participant to allocate more batches. The HashGrowBatchesReallocate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBatchesReallocate 
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 = 'IPC'
  AND wait_event = 'HashGrowBatchesReallocate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBatchesReallocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.26 - IPC: HashGrowBatchesRepartition

Waiting for other Parallel Hash participants to finish repartitioning
PostgreSQL wait event dossier
ClassIPC EventHashGrowBatchesRepartition VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for other Parallel Hash participants to finish repartitioning

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BATCHES_REPARTITION at src/backend/executor/nodeHash.c:1352 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:131. The instrumented operation is: Waiting for other Parallel Hash participants to finish repartitioning. The HashGrowBatchesRepartition path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBatchesRepartition 
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 = 'IPC'
  AND wait_event = 'HashGrowBatchesRepartition'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBatchesRepartition'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.27 - IPC: HashGrowBucketsElect

Waiting to elect a Parallel Hash participant to allocate more buckets
PostgreSQL wait event dossier
ClassIPC EventHashGrowBucketsElect VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to elect a Parallel Hash participant to allocate more buckets

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BUCKETS_ELECT at src/backend/executor/nodeHash.c:1669 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:132. The instrumented operation is: Waiting to elect a Parallel Hash participant to allocate more buckets. The HashGrowBucketsElect path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBucketsElect 
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 = 'IPC'
  AND wait_event = 'HashGrowBucketsElect'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBucketsElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.28 - IPC: HashGrowBucketsReallocate

Waiting for an elected Parallel Hash participant to finish allocating more buckets
PostgreSQL wait event dossier
ClassIPC EventHashGrowBucketsReallocate VersionsPG 16-18 Evidence4 source location(s)

Official description

Waiting for an elected Parallel Hash participant to finish allocating more buckets

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Earlier names: IPC/HashGrowBucketsAllocate (PG 13-15)

Trigger mechanism

WAIT_EVENT_HASH_GROW_BUCKETS_ALLOCATE at src/backend/executor/nodeHash.c:1588 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:383. The instrumented operation is: Waiting for an elected Parallel Hash participant to finish allocating more buckets. The HashGrowBucketsReallocate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBucketsReallocate 
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 = 'IPC'
  AND wait_event = 'HashGrowBucketsReallocate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBucketsReallocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.29 - IPC: HashGrowBucketsReinsert

Waiting for other Parallel Hash participants to finish inserting tuples into new buckets
PostgreSQL wait event dossier
ClassIPC EventHashGrowBucketsReinsert VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for other Parallel Hash participants to finish inserting tuples into new buckets

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

Trigger mechanism

WAIT_EVENT_HASH_GROW_BUCKETS_REINSERT at src/backend/executor/nodeHash.c:1733 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:134. The instrumented operation is: Waiting for other Parallel Hash participants to finish inserting tuples into new buckets. The HashGrowBucketsReinsert path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/HashGrowBucketsReinsert 
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 = 'IPC'
  AND wait_event = 'HashGrowBucketsReinsert'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'HashGrowBucketsReinsert'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.30 - IPC: LogicalApplySendData

Waiting for a logical replication leader apply process to send data to a parallel apply process
PostgreSQL wait event dossier
ClassIPC EventLogicalApplySendData VersionsPG 16-18 Evidence2 source location(s)

Official description

Waiting for a logical replication leader apply process to send data to a parallel apply process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_LOGICAL_APPLY_SEND_DATA at src/backend/replication/logical/applyparallelworker.c:1204 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:135. The instrumented operation is: Waiting for a logical replication leader apply process to send data to a parallel apply process. The LogicalApplySendData path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/LogicalApplySendData 
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 = 'IPC'
  AND wait_event = 'LogicalApplySendData'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'LogicalApplySendData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.31 - IPC: LogicalParallelApplyStateChange

Waiting for a logical replication parallel apply process to change state
PostgreSQL wait event dossier
ClassIPC EventLogicalParallelApplyStateChange VersionsPG 16-18 Evidence2 source location(s)

Official description

Waiting for a logical replication parallel apply process to change state

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE at src/backend/replication/logical/applyparallelworker.c:1276 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:136. The instrumented operation is: Waiting for a logical replication parallel apply process to change state. The LogicalParallelApplyStateChange path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/LogicalParallelApplyStateChange 
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 = 'IPC'
  AND wait_event = 'LogicalParallelApplyStateChange'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'LogicalParallelApplyStateChange'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.32 - IPC: LogicalSyncData

Waiting for a logical replication remote server to send data for initial table synchronization
PostgreSQL wait event dossier
ClassIPC EventLogicalSyncData VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a logical replication remote server to send data for initial table synchronization

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

Trigger mechanism

WAIT_EVENT_LOGICAL_SYNC_DATA at src/backend/replication/logical/tablesync.c:807 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:137. The instrumented operation is: Waiting for a logical replication remote server to send data for initial table synchronization. The LogicalSyncData path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/LogicalSyncData 
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 = 'IPC'
  AND wait_event = 'LogicalSyncData'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'LogicalSyncData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.33 - IPC: LogicalSyncStateChange

Waiting for a logical replication remote server to change state
PostgreSQL wait event dossier
ClassIPC EventLogicalSyncStateChange VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a logical replication remote server to change state

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

Trigger mechanism

WAIT_EVENT_LOGICAL_SYNC_STATE_CHANGE at src/backend/replication/logical/tablesync.c:214 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:138. The instrumented operation is: Waiting for a logical replication remote server to change state. The LogicalSyncStateChange path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/LogicalSyncStateChange 
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 = 'IPC'
  AND wait_event = 'LogicalSyncStateChange'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'LogicalSyncStateChange'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.34 - IPC: MessageQueueInternal

Waiting for another process to be attached to a shared message queue
PostgreSQL wait event dossier
ClassIPC EventMessageQueueInternal VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for another process to be attached to a shared message queue

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

Trigger mechanism

WAIT_EVENT_MESSAGE_QUEUE_INTERNAL at src/backend/storage/ipc/shm_mq.c:1254 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:139. The instrumented operation is: Waiting for another process to be attached to a shared message queue. The MessageQueueInternal path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/MessageQueueInternal 
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 = 'IPC'
  AND wait_event = 'MessageQueueInternal'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'MessageQueueInternal'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.35 - IPC: MessageQueuePutMessage

Waiting to write a protocol message to a shared message queue
PostgreSQL wait event dossier
ClassIPC EventMessageQueuePutMessage VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to write a protocol message to a shared message queue

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

Trigger mechanism

WAIT_EVENT_MESSAGE_QUEUE_PUT_MESSAGE at src/backend/libpq/pqmq.c:185 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:140. The instrumented operation is: Waiting to write a protocol message to a shared message queue. The MessageQueuePutMessage path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/MessageQueuePutMessage 
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 = 'IPC'
  AND wait_event = 'MessageQueuePutMessage'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'MessageQueuePutMessage'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.36 - IPC: MessageQueueReceive

Waiting to receive bytes from a shared message queue
PostgreSQL wait event dossier
ClassIPC EventMessageQueueReceive VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to receive bytes from a shared message queue

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

Trigger mechanism

WAIT_EVENT_MESSAGE_QUEUE_RECEIVE at src/backend/storage/ipc/shm_mq.c:1165 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:141. The instrumented operation is: Waiting to receive bytes from a shared message queue. The MessageQueueReceive path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/MessageQueueReceive 
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 = 'IPC'
  AND wait_event = 'MessageQueueReceive'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'MessageQueueReceive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.37 - IPC: MessageQueueSend

Waiting to send bytes to a shared message queue
PostgreSQL wait event dossier
ClassIPC EventMessageQueueSend VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to send bytes to a shared message queue

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

Trigger mechanism

WAIT_EVENT_MESSAGE_QUEUE_SEND at src/backend/storage/ipc/shm_mq.c:1019 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:142. The instrumented operation is: Waiting to send bytes to a shared message queue. The MessageQueueSend path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/MessageQueueSend 
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 = 'IPC'
  AND wait_event = 'MessageQueueSend'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'MessageQueueSend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.38 - IPC: MultixactCreation

Waiting for a multixact creation to complete
PostgreSQL wait event dossier
ClassIPC EventMultixactCreation VersionsPG 17-18 Evidence1 source location(s)

Official description

Waiting for a multixact creation to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

The catalog identity is present, but source audit found no live reporter in 17.8+, 18.2+. Known active ranges: 17.0-17.7, 18.0-18.1. The definition location below is retained as negative evidence; this exact release cannot emit the event from a core code path. Evidence: PostgreSQL 17.8 release note, PostgreSQL 18.2 release note.

Normal or trouble?

  • Normal: No live core occurrence is expected on the audited release.
  • Investigate: If telemetry shows it, verify the exact patch version, extension origin, and whether the sample is stale or came from a different server.

Diagnostic SQL

Sessions waiting on IPC/MultixactCreation 
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 = 'IPC'
  AND wait_event = 'MultixactCreation'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'MultixactCreation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.39 - IPC: ParallelBitmapScan

Waiting for parallel bitmap scan to become initialized
PostgreSQL wait event dossier
ClassIPC EventParallelBitmapScan VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for parallel bitmap scan to become initialized

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

Trigger mechanism

WAIT_EVENT_PARALLEL_BITMAP_SCAN at src/backend/executor/nodeBitmapHeapscan.c:437 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:144. The instrumented operation is: Waiting for parallel bitmap scan to become initialized. The ParallelBitmapScan path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ParallelBitmapScan 
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 = 'IPC'
  AND wait_event = 'ParallelBitmapScan'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ParallelBitmapScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.40 - IPC: ParallelCreateIndexScan

Waiting for parallel CREATE INDEX workers to finish heap scan
PostgreSQL wait event dossier
ClassIPC EventParallelCreateIndexScan VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for parallel CREATE INDEX workers to finish heap scan

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

Trigger mechanism

WAIT_EVENT_PARALLEL_CREATE_INDEX_SCAN at src/backend/access/brin/brin.c:2600 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:145. The instrumented operation is: Waiting for parallel CREATE INDEX workers to finish heap scan. The ParallelCreateIndexScan path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ParallelCreateIndexScan 
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 = 'IPC'
  AND wait_event = 'ParallelCreateIndexScan'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ParallelCreateIndexScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.41 - IPC: ParallelFinish

Waiting for parallel workers to finish computing
PostgreSQL wait event dossier
ClassIPC EventParallelFinish VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for parallel workers to finish computing

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

Trigger mechanism

WAIT_EVENT_PARALLEL_FINISH at src/backend/access/transam/parallel.c:894 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:146. The instrumented operation is: Waiting for parallel workers to finish computing. The ParallelFinish path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ParallelFinish 
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 = 'IPC'
  AND wait_event = 'ParallelFinish'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ParallelFinish'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.42 - IPC: ProcSignalBarrier

Waiting for a barrier event to be processed by all backends
PostgreSQL wait event dossier
ClassIPC EventProcSignalBarrier VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a barrier event to be processed by all backends

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

Trigger mechanism

WAIT_EVENT_PROC_SIGNAL_BARRIER at src/backend/storage/ipc/procsignal.c:458 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:148. The instrumented operation is: Waiting for a barrier event to be processed by all backends. The ProcSignalBarrier path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ProcSignalBarrier 
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 = 'IPC'
  AND wait_event = 'ProcSignalBarrier'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ProcSignalBarrier'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.43 - IPC: ProcarrayGroupUpdate

Waiting for the group leader to clear the transaction ID at transaction end
PostgreSQL wait event dossier
ClassIPC EventProcarrayGroupUpdate VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for the group leader to clear the transaction ID at transaction end

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: IPC/ProcArrayGroupUpdate (PG 13-16)

Trigger mechanism

WAIT_EVENT_PROCARRAY_GROUP_UPDATE at src/backend/storage/ipc/procarray.c:829 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:428. The instrumented operation is: Waiting for the group leader to clear the transaction ID at transaction end. The ProcarrayGroupUpdate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ProcarrayGroupUpdate 
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 = 'IPC'
  AND wait_event = 'ProcarrayGroupUpdate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ProcarrayGroupUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.44 - IPC: Promote

Waiting for standby promotion
PostgreSQL wait event dossier
ClassIPC EventPromote VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for standby promotion

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

Trigger mechanism

WAIT_EVENT_PROMOTE at src/backend/access/transam/xlogfuncs.c:731 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:149. The instrumented operation is: Waiting for standby promotion. The Promote path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/Promote 
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 = 'IPC'
  AND wait_event = 'Promote'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'Promote'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.45 - IPC: RecoveryConflictSnapshot

Waiting for recovery conflict resolution for a vacuum cleanup
PostgreSQL wait event dossier
ClassIPC EventRecoveryConflictSnapshot VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for recovery conflict resolution for a vacuum cleanup

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

Trigger mechanism

WAIT_EVENT_RECOVERY_CONFLICT_SNAPSHOT at src/backend/storage/ipc/standby.c:493 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:150. The instrumented operation is: Waiting for recovery conflict resolution for a vacuum cleanup. The RecoveryConflictSnapshot path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/RecoveryConflictSnapshot 
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 = 'IPC'
  AND wait_event = 'RecoveryConflictSnapshot'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'RecoveryConflictSnapshot'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.46 - IPC: RecoveryConflictTablespace

Waiting for recovery conflict resolution for dropping a tablespace
PostgreSQL wait event dossier
ClassIPC EventRecoveryConflictTablespace VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for recovery conflict resolution for dropping a tablespace

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

Trigger mechanism

WAIT_EVENT_RECOVERY_CONFLICT_TABLESPACE at src/backend/storage/ipc/standby.c:564 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:151. The instrumented operation is: Waiting for recovery conflict resolution for dropping a tablespace. The RecoveryConflictTablespace path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/RecoveryConflictTablespace 
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 = 'IPC'
  AND wait_event = 'RecoveryConflictTablespace'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'RecoveryConflictTablespace'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.47 - IPC: RecoveryEndCommand

Waiting for recovery_end_command to complete
PostgreSQL wait event dossier
ClassIPC EventRecoveryEndCommand VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for recovery_end_command to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_RECOVERY_END_COMMAND at src/backend/access/transam/xlog.c:5337 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:152. The instrumented operation is: Waiting for recovery_end_command to complete. The RecoveryEndCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/RecoveryEndCommand 
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 = 'IPC'
  AND wait_event = 'RecoveryEndCommand'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'RecoveryEndCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.48 - IPC: RecoveryPause

Waiting for recovery to be resumed
PostgreSQL wait event dossier
ClassIPC EventRecoveryPause VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for recovery to be resumed

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

Trigger mechanism

WAIT_EVENT_RECOVERY_PAUSE at src/backend/access/transam/xlogrecovery.c:2994 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:153. The instrumented operation is: Waiting for recovery to be resumed. The RecoveryPause path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/RecoveryPause 
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 = 'IPC'
  AND wait_event = 'RecoveryPause'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'RecoveryPause'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.49 - IPC: ReplicationOriginDrop

Waiting for a replication origin to become inactive so it can be dropped
PostgreSQL wait event dossier
ClassIPC EventReplicationOriginDrop VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a replication origin to become inactive so it can be dropped

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

Trigger mechanism

WAIT_EVENT_REPLICATION_ORIGIN_DROP at src/backend/replication/logical/origin.c:408 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:154. The instrumented operation is: Waiting for a replication origin to become inactive so it can be dropped. The ReplicationOriginDrop path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ReplicationOriginDrop 
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 = 'IPC'
  AND wait_event = 'ReplicationOriginDrop'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ReplicationOriginDrop'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.50 - IPC: ReplicationSlotDrop

Waiting for a replication slot to become inactive so it can be dropped
PostgreSQL wait event dossier
ClassIPC EventReplicationSlotDrop VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for a replication slot to become inactive so it can be dropped

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

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOT_DROP at src/backend/replication/slot.c:657 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:155. The instrumented operation is: Waiting for a replication slot to become inactive so it can be dropped. The ReplicationSlotDrop path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/ReplicationSlotDrop 
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 = 'IPC'
  AND wait_event = 'ReplicationSlotDrop'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'ReplicationSlotDrop'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.51 - IPC: RestoreCommand

Waiting for restore_command to complete
PostgreSQL wait event dossier
ClassIPC EventRestoreCommand VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting for restore_command to complete

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_RESTORE_COMMAND at src/backend/access/transam/xlogarchive.c:162 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:156. The instrumented operation is: Waiting for restore_command to complete. The RestoreCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/RestoreCommand 
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 = 'IPC'
  AND wait_event = 'RestoreCommand'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'RestoreCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.52 - IPC: SafeSnapshot

Waiting to obtain a valid snapshot for a READ ONLY DEFERRABLE transaction
PostgreSQL wait event dossier
ClassIPC EventSafeSnapshot VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to obtain a valid snapshot for a READ ONLY DEFERRABLE transaction

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

Trigger mechanism

WAIT_EVENT_SAFE_SNAPSHOT at src/backend/storage/lmgr/predicate.c:1589 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:157. The instrumented operation is: Waiting to obtain a valid snapshot for a READ ONLY DEFERRABLE transaction. The SafeSnapshot path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/SafeSnapshot 
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 = 'IPC'
  AND wait_event = 'SafeSnapshot'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'SafeSnapshot'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.53 - IPC: SyncRep

Waiting for confirmation from a remote server during synchronous replication
PostgreSQL wait event dossier
ClassIPC EventSyncRep VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for confirmation from a remote server during synchronous replication

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

Trigger mechanism

WAIT_EVENT_SYNC_REP at src/backend/replication/syncrep.c:332 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:158. The instrumented operation is: Waiting for confirmation from a remote server during synchronous replication. The SyncRep path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/SyncRep 
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 = 'IPC'
  AND wait_event = 'SyncRep'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'SyncRep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.54 - IPC: WalReceiverExit

Waiting for the WAL receiver to exit
PostgreSQL wait event dossier
ClassIPC EventWalReceiverExit VersionsPG 14-18 Evidence2 source location(s)

Official description

Waiting for the WAL receiver to exit

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_RECEIVER_EXIT at src/backend/replication/walreceiverfuncs.c:228 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:159. The instrumented operation is: Waiting for the WAL receiver to exit. The WalReceiverExit path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/WalReceiverExit 
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 = 'IPC'
  AND wait_event = 'WalReceiverExit'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'WalReceiverExit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.55 - IPC: WalReceiverUpstreamCatchup

Waiting for upstream server WAL flush position to catch up to requested start point
PostgreSQL wait event dossier
ClassIPC EventWalReceiverUpstreamCatchup VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for upstream server WAL flush position to catch up to requested start point

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓
Important

Patch-level availability: Observed in 17.11+ and 18.6+; it is absent from 17.10 and 18.4, so the major-only range is insufficient.

Trigger mechanism

WAIT_EVENT_WAL_RECEIVER_UPSTREAM_CATCHUP at src/backend/replication/walreceiver.c:398 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:165. The instrumented operation is: Waiting for upstream server WAL flush position to catch up to requested start point. The WalReceiverUpstreamCatchup path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/WalReceiverUpstreamCatchup 
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 = 'IPC'
  AND wait_event = 'WalReceiverUpstreamCatchup'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'WalReceiverUpstreamCatchup'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.56 - IPC: WalReceiverWaitStart

Waiting for startup process to send initial data for streaming replication
PostgreSQL wait event dossier
ClassIPC EventWalReceiverWaitStart VersionsPG 14-18 Evidence4 source location(s)

Official description

Waiting for startup process to send initial data for streaming replication

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

Earlier names: Client/WalReceiverWaitStart (PG 13)

Trigger mechanism

WAIT_EVENT_WAL_RECEIVER_WAIT_START at src/backend/postmaster/pgstat.c:3738 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/postmaster/pgstat.c:3739. The instrumented operation is: Waiting for startup process to send initial data for streaming replication. The WalReceiverWaitStart path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/WalReceiverWaitStart 
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 = 'IPC'
  AND wait_event = 'WalReceiverWaitStart'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'WalReceiverWaitStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.57 - IPC: WalSummaryReady

Waiting for a new WAL summary to be generated
PostgreSQL wait event dossier
ClassIPC EventWalSummaryReady VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for a new WAL summary to be generated

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_SUMMARY_READY at src/backend/postmaster/walsummarizer.c:821 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:161. The instrumented operation is: Waiting for a new WAL summary to be generated. The WalSummaryReady path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/WalSummaryReady 
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 = 'IPC'
  AND wait_event = 'WalSummaryReady'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'WalSummaryReady'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

7.58 - IPC: XactGroupUpdate

Waiting for the group leader to update transaction status at transaction end
PostgreSQL wait event dossier
ClassIPC EventXactGroupUpdate VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for the group leader to update transaction status at transaction end

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

Trigger mechanism

WAIT_EVENT_XACT_GROUP_UPDATE at src/backend/access/transam/clog.c:535 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:162. The instrumented operation is: Waiting for the group leader to update transaction status at transaction end. The XactGroupUpdate path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

  • Normal: Brief rendezvous is normal when every participant continues to advance.
  • Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

Sessions waiting on IPC/XactGroupUpdate 
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 = 'IPC'
  AND wait_event = 'XactGroupUpdate'
ORDER BY query_age DESC NULLS LAST;
Current IPC 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 = 'IPC'
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 = 'IPC'
  AND a.wait_event = 'XactGroupUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the peer or phase named by the event.
  2. Inspect that participant’s wait, error, and progress state.
  3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

Related controls and signals

8 - Client waits

PostgreSQL waiting for an application, network socket, TLS/GSS handshake, or replication client.

Client flips the usual suspicion: PostgreSQL is ready to read, write, or complete a protocol step, and the remote side or network has not progressed. A large client-wait population is often normal for pooled idle connections.

State and transaction age decide severity

ClientRead plus state = 'idle' is expected. The same event with idle in transaction and an old xact_start can retain locks, snapshots, and dead tuples. ClientWrite on active sessions suggests the server cannot hand results to the consumer fast enough.

  • Normal: idle pooled sessions waiting for the next command.
  • Watch: old idle in transaction, active ClientWrite, handshake waits, or application latency at the same time.
  • Urgent: clients stop consuming results, connection slots are exhausted, open transactions block cleanup, or a replication client disconnects repeatedly.

Events to recognize

Event First owner to contact
ClientRead Application/connection pool
ClientWrite Application consumer or network
GssOpenServer Authentication/network path
SslOpenServer TLS handshake path
LibpqwalreceiverReceive Upstream primary/network
WalSenderWriteData Standby or replication client

Common misreads

  • “Most sessions are in ClientRead” is not a database bottleneck without state, transaction age, and pool sizing.
  • Cancelling an idle client does not fix an oversized pool; it only makes the pool reconnect.
  • ClientWrite can be caused by a slow consumer even when the database host network looks idle.
  • Replication-flavoured Client waits belong to the same protocol boundary but have different operational owners.

8.1 - Client: ClientRead

Waiting to read data from the client
PostgreSQL wait event dossier
ClassClient EventClientRead VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to read data from the client

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

Trigger mechanism

WAIT_EVENT_CLIENT_READ at src/backend/libpq/be-secure.c:219 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:85. The instrumented operation is: Waiting to read data from the client. The frontend protocol path reports ClientRead immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/ClientRead 
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 = 'Client'
  AND wait_event = 'ClientRead'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'ClientRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.2 - Client: ClientWrite

Waiting to write data to the client
PostgreSQL wait event dossier
ClassClient EventClientWrite VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to write data to the client

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

Trigger mechanism

WAIT_EVENT_CLIENT_WRITE at src/backend/libpq/be-secure.c:344 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:86. The instrumented operation is: Waiting to write data to the client. The frontend protocol path reports ClientWrite immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/ClientWrite 
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 = 'Client'
  AND wait_event = 'ClientWrite'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'ClientWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.3 - Client: GssOpenServer

Waiting to read data from the client while establishing a GSSAPI session
PostgreSQL wait event dossier
ClassClient EventGssOpenServer VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting to read data from the client while establishing a GSSAPI session

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Client/GSSOpenServer (PG 13-16)

Trigger mechanism

WAIT_EVENT_GSS_OPEN_SERVER at src/backend/libpq/be-secure-gssapi.c:461 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:277. The instrumented operation is: Waiting to read data from the client while establishing a GSSAPI session. The frontend protocol path reports GssOpenServer immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/GssOpenServer 
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 = 'Client'
  AND wait_event = 'GssOpenServer'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'GssOpenServer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.4 - Client: LibpqwalreceiverConnect

Waiting in WAL receiver to establish connection to remote server
PostgreSQL wait event dossier
ClassClient EventLibpqwalreceiverConnect VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in WAL receiver to establish connection to remote server

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Client/LibPQWalReceiverConnect (PG 13-16)

Trigger mechanism

WAIT_EVENT_LIBPQWALRECEIVER_CONNECT at src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:231 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:280. The instrumented operation is: Waiting in WAL receiver to establish connection to remote server. The frontend protocol path reports LibpqwalreceiverConnect immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/LibpqwalreceiverConnect 
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 = 'Client'
  AND wait_event = 'LibpqwalreceiverConnect'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'LibpqwalreceiverConnect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.5 - Client: LibpqwalreceiverReceive

Waiting in WAL receiver to receive data from remote server
PostgreSQL wait event dossier
ClassClient EventLibpqwalreceiverReceive VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in WAL receiver to receive data from remote server

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Client/LibPQWalReceiverReceive (PG 13-16)

Trigger mechanism

WAIT_EVENT_LIBPQWALRECEIVER_RECEIVE at src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:876 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:283. The instrumented operation is: Waiting in WAL receiver to receive data from remote server. The frontend protocol path reports LibpqwalreceiverReceive immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/LibpqwalreceiverReceive 
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 = 'Client'
  AND wait_event = 'LibpqwalreceiverReceive'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'LibpqwalreceiverReceive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.6 - Client: SslOpenServer

Waiting for SSL while attempting connection
PostgreSQL wait event dossier
ClassClient EventSslOpenServer VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for SSL while attempting connection

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Client/SSLOpenServer (PG 13-16)

Trigger mechanism

WAIT_EVENT_SSL_OPEN_SERVER at src/backend/libpq/be-secure-openssl.c:508 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:286. The instrumented operation is: Waiting for SSL while attempting connection. The frontend protocol path reports SslOpenServer immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/SslOpenServer 
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 = 'Client'
  AND wait_event = 'SslOpenServer'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'SslOpenServer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.7 - Client: WaitForStandbyConfirmation

Waiting for WAL to be received and flushed by the physical standby
PostgreSQL wait event dossier
ClassClient EventWaitForStandbyConfirmation VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for WAL to be received and flushed by the physical standby

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAIT_FOR_STANDBY_CONFIRMATION at src/backend/replication/slot.c:3083 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:91. The instrumented operation is: Waiting for WAL to be received and flushed by the physical standby. The frontend protocol path reports WaitForStandbyConfirmation immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/WaitForStandbyConfirmation 
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 = 'Client'
  AND wait_event = 'WaitForStandbyConfirmation'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'WaitForStandbyConfirmation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.8 - Client: WalSenderWaitForWal

Waiting for WAL to be flushed in WAL sender process
PostgreSQL wait event dossier
ClassClient EventWalSenderWaitForWal VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting for WAL to be flushed in WAL sender process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Client/WalSenderWaitForWAL (PG 13-16)

Trigger mechanism

WAIT_EVENT_WAL_SENDER_WAIT_WAL at src/backend/replication/walsender.c:1714 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:289. The instrumented operation is: Waiting for WAL to be flushed in WAL sender process. The frontend protocol path reports WalSenderWaitForWal immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/WalSenderWaitForWal 
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 = 'Client'
  AND wait_event = 'WalSenderWaitForWal'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'WalSenderWaitForWal'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

8.9 - Client: WalSenderWriteData

Waiting for any activity when processing replies from WAL receiver in WAL sender process
PostgreSQL wait event dossier
ClassClient EventWalSenderWriteData VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting for any activity when processing replies from WAL receiver in WAL sender process

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

Trigger mechanism

WAIT_EVENT_WAL_SENDER_WRITE_DATA at src/backend/replication/walsender.c:1653 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:93. The instrumented operation is: Waiting for any activity when processing replies from WAL receiver in WAL sender process. The frontend protocol path reports WalSenderWriteData immediately before a socket, TLS/GSS, or replication-client operation blocks. PostgreSQL is waiting for the remote side or network to progress.

Normal or trouble?

  • Normal: Idle ClientRead sessions are normal connection-pool inventory.
  • Investigate: Investigate active writes, handshakes, old idle-in-transaction sessions, connection exhaustion, or replication-client stalls.

Diagnostic SQL

Sessions waiting on Client/WalSenderWriteData 
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 = 'Client'
  AND wait_event = 'WalSenderWriteData'
ORDER BY query_age DESC NULLS LAST;
Current Client 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 = 'Client'
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 = 'Client'
  AND a.wait_event = 'WalSenderWriteData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Check state and transaction age before counting the wait as load.
  2. Correlate with the owning application, pool, and network path.
  3. Fix consumer backpressure or pool policy rather than repeatedly terminating connections.

Source evidence

Related controls and signals

9 - Activity waits

Background processes sleeping in their main loop until work arrives.

Activity is mostly the sound of a healthy idle background process. Archiver, checkpointer, WAL writer, autovacuum launcher, replication workers, and related processes publish distinct names while waiting in their main loop.

Interpret by backend type

These events should not be counted in a foreground “waiting session percentage.” Instead, compare the event with backend_type and ask whether that process should currently have work.

  • Normal: one matching background process waits in its documented main loop.
  • Watch: the event appears on the wrong backend type, the process is absent, or work queues grow while it remains idle.
  • Urgent: required background progress has stopped—archiving backlog, no checkpoints, replication not advancing, or shutdown unable to finish.

Events to recognize

Event Expected process
AutovacuumMain Autovacuum launcher between scheduling cycles
CheckpointerMain Checkpointer awaiting work
WalWriterMain WAL writer main loop
ArchiverMain Archiver waiting for a completed segment
WalReceiverMain WAL receiver main loop
RecoveryWalStream Startup process waiting for streamed WAL
IoWorkerMain PG18 asynchronous I/O worker awaiting work

Common misreads

  • Activity waits dominating all backends can simply mean the cluster is idle.
  • An idle checkpointer is not evidence that checkpoints are disabled.
  • A normal wait name does not prove progress; check the queue/backlog and timestamps.
  • Missing expected background processes is often more important than seeing their Activity wait.

9.1 - Activity: ArchiverMain

Waiting in main loop of archiver process
PostgreSQL wait event dossier
ClassActivity EventArchiverMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of archiver process

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

Trigger mechanism

WAIT_EVENT_ARCHIVER_MAIN at src/backend/postmaster/pgarch.c:362 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:54. The instrumented operation is: Waiting in main loop of archiver process. The ArchiverMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/ArchiverMain 
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 = 'Activity'
  AND wait_event = 'ArchiverMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'ArchiverMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.2 - Activity: AutovacuumMain

Waiting in main loop of autovacuum launcher process
PostgreSQL wait event dossier
ClassActivity EventAutovacuumMain VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in main loop of autovacuum launcher process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Activity/AutoVacuumMain (PG 13-16)

Trigger mechanism

WAIT_EVENT_AUTOVACUUM_MAIN at src/backend/postmaster/autovacuum.c:667 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:216. The instrumented operation is: Waiting in main loop of autovacuum launcher process. The AutovacuumMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/AutovacuumMain 
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 = 'Activity'
  AND wait_event = 'AutovacuumMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'AutovacuumMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.3 - Activity: BgwriterHibernate

Waiting in background writer process, hibernating
PostgreSQL wait event dossier
ClassActivity EventBgwriterHibernate VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in background writer process, hibernating

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Activity/BgWriterHibernate (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWRITER_HIBERNATE at src/backend/postmaster/bgwriter.c:339 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:219. The instrumented operation is: Waiting in background writer process, hibernating. The BgwriterHibernate background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/BgwriterHibernate 
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 = 'Activity'
  AND wait_event = 'BgwriterHibernate'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'BgwriterHibernate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.4 - Activity: BgwriterMain

Waiting in main loop of background writer process
PostgreSQL wait event dossier
ClassActivity EventBgwriterMain VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in main loop of background writer process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Activity/BgWriterMain (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWRITER_MAIN at src/backend/postmaster/bgwriter.c:311 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:222. The instrumented operation is: Waiting in main loop of background writer process. The BgwriterMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/BgwriterMain 
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 = 'Activity'
  AND wait_event = 'BgwriterMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'BgwriterMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.5 - Activity: CheckpointerMain

Waiting in main loop of checkpointer process
PostgreSQL wait event dossier
ClassActivity EventCheckpointerMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of checkpointer process

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

Trigger mechanism

WAIT_EVENT_CHECKPOINTER_MAIN at src/backend/postmaster/checkpointer.c:583 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:58. The instrumented operation is: Waiting in main loop of checkpointer process. The CheckpointerMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/CheckpointerMain 
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 = 'Activity'
  AND wait_event = 'CheckpointerMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'CheckpointerMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.6 - Activity: CheckpointerShutdown

Waiting for checkpointer process to be terminated
PostgreSQL wait event dossier
ClassActivity EventCheckpointerShutdown VersionsPG 18 Evidence2 source location(s)

Official description

Waiting for checkpointer process to be terminated

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_CHECKPOINTER_SHUTDOWN at src/backend/postmaster/checkpointer.c:631 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:59. The instrumented operation is: Waiting for checkpointer process to be terminated. The CheckpointerShutdown background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/CheckpointerShutdown 
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 = 'Activity'
  AND wait_event = 'CheckpointerShutdown'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'CheckpointerShutdown'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.7 - Activity: IoWorkerMain

Waiting in main loop of IO Worker process
PostgreSQL wait event dossier
ClassActivity EventIoWorkerMain VersionsPG 18 Evidence2 source location(s)

Official description

Waiting in main loop of IO Worker process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

Trigger mechanism

WAIT_EVENT_IO_WORKER_MAIN at src/backend/storage/aio/method_worker.c:573 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:60. The instrumented operation is: Waiting in main loop of IO Worker process. The IoWorkerMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/IoWorkerMain 
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 = 'Activity'
  AND wait_event = 'IoWorkerMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'IoWorkerMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.8 - Activity: LogicalApplyMain

Waiting in main loop of logical replication apply process
PostgreSQL wait event dossier
ClassActivity EventLogicalApplyMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of logical replication apply process

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

Trigger mechanism

WAIT_EVENT_LOGICAL_APPLY_MAIN at src/backend/replication/logical/worker.c:3766 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:61. The instrumented operation is: Waiting in main loop of logical replication apply process. The LogicalApplyMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/LogicalApplyMain 
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 = 'Activity'
  AND wait_event = 'LogicalApplyMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'LogicalApplyMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.9 - Activity: LogicalLauncherMain

Waiting in main loop of logical replication launcher process
PostgreSQL wait event dossier
ClassActivity EventLogicalLauncherMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of logical replication launcher process

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

Trigger mechanism

WAIT_EVENT_LOGICAL_LAUNCHER_MAIN at src/backend/replication/logical/launcher.c:1242 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:62. The instrumented operation is: Waiting in main loop of logical replication launcher process. The LogicalLauncherMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/LogicalLauncherMain 
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 = 'Activity'
  AND wait_event = 'LogicalLauncherMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'LogicalLauncherMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.10 - Activity: LogicalParallelApplyMain

Waiting in main loop of logical replication parallel apply process
PostgreSQL wait event dossier
ClassActivity EventLogicalParallelApplyMain VersionsPG 16-18 Evidence2 source location(s)

Official description

Waiting in main loop of logical replication parallel apply process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_LOGICAL_PARALLEL_APPLY_MAIN at src/backend/replication/logical/applyparallelworker.c:810 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:63. The instrumented operation is: Waiting in main loop of logical replication parallel apply process. The LogicalParallelApplyMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/LogicalParallelApplyMain 
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 = 'Activity'
  AND wait_event = 'LogicalParallelApplyMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'LogicalParallelApplyMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.11 - Activity: PgStatMain

Waiting in main loop of statistics collector process.
PostgreSQL wait event dossier
ClassActivity EventPgStatMain VersionsPG 13-14 Evidence2 source location(s)

Official description

Waiting in main loop of statistics collector process.

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ — — — —

Trigger mechanism

WAIT_EVENT_PGSTAT_MAIN at src/backend/postmaster/pgstat.c:3425 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:234. The instrumented operation is: Waiting in main loop of statistics collector process. The PgStatMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/PgStatMain 
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 = 'Activity'
  AND wait_event = 'PgStatMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'PgStatMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.12 - Activity: RecoveryWalStream

Waiting in main loop of startup process for WAL to arrive, during streaming recovery
PostgreSQL wait event dossier
ClassActivity EventRecoveryWalStream VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of startup process for WAL to arrive, during streaming recovery

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

Trigger mechanism

WAIT_EVENT_RECOVERY_WAL_STREAM at src/backend/access/transam/xlogrecovery.c:4038 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:64. The instrumented operation is: Waiting in main loop of startup process for WAL to arrive, during streaming recovery. The RecoveryWalStream background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/RecoveryWalStream 
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 = 'Activity'
  AND wait_event = 'RecoveryWalStream'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'RecoveryWalStream'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.13 - Activity: ReplicationSlotsyncMain

Waiting in main loop of slot sync worker
PostgreSQL wait event dossier
ClassActivity EventReplicationSlotsyncMain VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting in main loop of slot sync worker

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOTSYNC_MAIN at src/backend/replication/logical/slotsync.c:1369 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:65. The instrumented operation is: Waiting in main loop of slot sync worker. The ReplicationSlotsyncMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/ReplicationSlotsyncMain 
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 = 'Activity'
  AND wait_event = 'ReplicationSlotsyncMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'ReplicationSlotsyncMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.14 - Activity: ReplicationSlotsyncShutdown

Waiting for slot sync worker to shut down
PostgreSQL wait event dossier
ClassActivity EventReplicationSlotsyncShutdown VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting for slot sync worker to shut down

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_REPLICATION_SLOTSYNC_SHUTDOWN at src/backend/replication/logical/slotsync.c:1732 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:66. The instrumented operation is: Waiting for slot sync worker to shut down. The ReplicationSlotsyncShutdown background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/ReplicationSlotsyncShutdown 
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 = 'Activity'
  AND wait_event = 'ReplicationSlotsyncShutdown'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'ReplicationSlotsyncShutdown'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.15 - Activity: SysloggerMain

Waiting in main loop of syslogger process
PostgreSQL wait event dossier
ClassActivity EventSysloggerMain VersionsPG 17-18 Evidence4 source location(s)

Official description

Waiting in main loop of syslogger process

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Earlier names: Activity/SysLoggerMain (PG 13-16)

Trigger mechanism

WAIT_EVENT_SYSLOGGER_MAIN at src/backend/postmaster/syslogger.c:487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:240. The instrumented operation is: Waiting in main loop of syslogger process. The SysloggerMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/SysloggerMain 
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 = 'Activity'
  AND wait_event = 'SysloggerMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'SysloggerMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.16 - Activity: WalReceiverMain

Waiting in main loop of WAL receiver process
PostgreSQL wait event dossier
ClassActivity EventWalReceiverMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of WAL receiver process

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

Trigger mechanism

WAIT_EVENT_WAL_RECEIVER_MAIN at src/backend/replication/walreceiver.c:600 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:68. The instrumented operation is: Waiting in main loop of WAL receiver process. The WalReceiverMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/WalReceiverMain 
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 = 'Activity'
  AND wait_event = 'WalReceiverMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'WalReceiverMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.17 - Activity: WalSenderMain

Waiting in main loop of WAL sender process
PostgreSQL wait event dossier
ClassActivity EventWalSenderMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of WAL sender process

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

Trigger mechanism

WAIT_EVENT_WAL_SENDER_MAIN at src/backend/replication/walsender.c:2963 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:69. The instrumented operation is: Waiting in main loop of WAL sender process. The WalSenderMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/WalSenderMain 
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 = 'Activity'
  AND wait_event = 'WalSenderMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'WalSenderMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.18 - Activity: WalSummarizerWal

Waiting in WAL summarizer for more WAL to be generated
PostgreSQL wait event dossier
ClassActivity EventWalSummarizerWal VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting in WAL summarizer for more WAL to be generated

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_SUMMARIZER_WAL at src/backend/postmaster/walsummarizer.c:1798 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:70. The instrumented operation is: Waiting in WAL summarizer for more WAL to be generated. The WalSummarizerWal background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/WalSummarizerWal 
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 = 'Activity'
  AND wait_event = 'WalSummarizerWal'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'WalSummarizerWal'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

9.19 - Activity: WalWriterMain

Waiting in main loop of WAL writer process
PostgreSQL wait event dossier
ClassActivity EventWalWriterMain VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in main loop of WAL writer process

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

Trigger mechanism

WAIT_EVENT_WAL_WRITER_MAIN at src/backend/postmaster/walwriter.c:271 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:71. The instrumented operation is: Waiting in main loop of WAL writer process. The WalWriterMain background path reports this event around its latch wait when its main loop has no immediate work. A signal, timeout, or new work clears the sleep and the process loops again.

Normal or trouble?

  • Normal: This is normally expected idleness for the matching background process.
  • Investigate: Investigate only when queued work or a shutdown/failover deadline is not advancing while the process remains here, or when the event appears on an unexpected backend type.

Diagnostic SQL

Sessions waiting on Activity/WalWriterMain 
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 = 'Activity'
  AND wait_event = 'WalWriterMain'
ORDER BY query_age DESC NULLS LAST;
Current Activity 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 = 'Activity'
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 = 'Activity'
  AND a.wait_event = 'WalWriterMain'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Match the row to backend_type.
  2. Inspect the process-specific backlog and last-progress timestamp.
  3. Fix the missing work signal or stalled upstream phase; do not kill a normally idle worker.

Source evidence

Related controls and signals

10 - Timeout waits

Deliberate sleeps, retry intervals, throttles, and rate-limiting delays.

Timeout usually means PostgreSQL intentionally delayed work until a timer expires. The important question is not “why is the kernel slow?” but “which policy or safety mechanism inserted this delay?”

Identify the policy owner

Vacuum cost delay, recovery delay, backup throttling, checkpoint spreading, retry intervals, and pg_sleep() are designed waits. They become a problem when the policy no longer matches the service objective or when another bottleneck makes the delay recur excessively.

  • Normal: the configured policy is active and useful work advances at the expected rate.
  • Watch: foreground latency includes a deliberate sleep, or maintenance falls behind while spending much of its time throttled.
  • Urgent: recovery/backup/checkpoint deadlines are missed, a spin delay persists, or an operator did not intend the policy.

Events to recognize

Event Policy
VacuumDelay Cost-based vacuum throttling
CheckpointWriteDelay Spreading checkpoint writes across the interval
RecoveryApplyDelay Intentional delayed standby replay
RecoveryRetrieveRetryInterval Retrying unavailable WAL sources
BaseBackupThrottle Backup transfer-rate limit
PgSleep SQL or internal sleep function
SpinDelay Backoff while acquiring a contended spinlock

Common misreads

  • Timeout does not mean a statement or lock timeout fired; it means the process is currently sleeping on a timer.
  • Reducing vacuum delay can recover maintenance throughput but also increase I/O and CPU pressure.
  • RecoveryApplyDelay can be intentional disaster-recovery policy.
  • Persistent SpinDelay deserves escalation: a spinlock should normally be held for an extremely short time.

10.1 - Timeout: BaseBackupThrottle

Waiting during base backup when throttling activity
PostgreSQL wait event dossier
ClassTimeout EventBaseBackupThrottle VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting during base backup when throttling activity

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

Trigger mechanism

WAIT_EVENT_BASE_BACKUP_THROTTLE at src/backend/backup/basebackup_throttle.c:178 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:175. The instrumented operation is: Waiting during base backup when throttling activity. The BaseBackupThrottle path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/BaseBackupThrottle 
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 = 'Timeout'
  AND wait_event = 'BaseBackupThrottle'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'BaseBackupThrottle'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.2 - Timeout: CheckpointWriteDelay

Waiting between writes while performing a checkpoint
PostgreSQL wait event dossier
ClassTimeout EventCheckpointWriteDelay VersionsPG 14-18 Evidence2 source location(s)

Official description

Waiting between writes while performing a checkpoint

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_CHECKPOINT_WRITE_DELAY at src/backend/postmaster/checkpointer.c:814 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:176. The instrumented operation is: Waiting between writes while performing a checkpoint. The CheckpointWriteDelay path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/CheckpointWriteDelay 
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 = 'Timeout'
  AND wait_event = 'CheckpointWriteDelay'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'CheckpointWriteDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.3 - Timeout: PgSleep

Waiting due to a call to pg_sleep or a sibling function
PostgreSQL wait event dossier
ClassTimeout EventPgSleep VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting due to a call to pg_sleep or a sibling function

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

Trigger mechanism

WAIT_EVENT_PG_SLEEP at src/backend/utils/adt/misc.c:409 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:177. The instrumented operation is: Waiting due to a call to pg_sleep or a sibling function. The PgSleep path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/PgSleep 
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 = 'Timeout'
  AND wait_event = 'PgSleep'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'PgSleep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.4 - Timeout: RecoveryApplyDelay

Waiting to apply WAL during recovery because of a delay setting
PostgreSQL wait event dossier
ClassTimeout EventRecoveryApplyDelay VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to apply WAL during recovery because of a delay setting

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

Trigger mechanism

WAIT_EVENT_RECOVERY_APPLY_DELAY at src/backend/access/transam/xlogrecovery.c:3092 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:178. The instrumented operation is: Waiting to apply WAL during recovery because of a delay setting. The RecoveryApplyDelay path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/RecoveryApplyDelay 
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 = 'Timeout'
  AND wait_event = 'RecoveryApplyDelay'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RecoveryApplyDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.5 - Timeout: RecoveryRetrieveRetryInterval

Waiting during recovery when WAL data is not available from any source (pg_wal, archive or stream)
PostgreSQL wait event dossier
ClassTimeout EventRecoveryRetrieveRetryInterval VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting during recovery when WAL data is not available from any source (pg_wal, archive or stream)

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

Trigger mechanism

WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL at src/backend/access/transam/xlogrecovery.c:3764 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:179. The instrumented operation is: Waiting during recovery when WAL data is not available from any source (pg_wal, archive or stream). The RecoveryRetrieveRetryInterval path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/RecoveryRetrieveRetryInterval 
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 = 'Timeout'
  AND wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.6 - Timeout: RegisterSyncRequest

Waiting while sending synchronization requests to the checkpointer, because the request queue is full
PostgreSQL wait event dossier
ClassTimeout EventRegisterSyncRequest VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting while sending synchronization requests to the checkpointer, because the request queue is full

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

Trigger mechanism

WAIT_EVENT_REGISTER_SYNC_REQUEST at src/backend/storage/sync/sync.c:615 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:180. The instrumented operation is: Waiting while sending synchronization requests to the checkpointer, because the request queue is full. The RegisterSyncRequest path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/RegisterSyncRequest 
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 = 'Timeout'
  AND wait_event = 'RegisterSyncRequest'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RegisterSyncRequest'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.7 - Timeout: SpinDelay

Waiting while acquiring a contended spinlock
PostgreSQL wait event dossier
ClassTimeout EventSpinDelay VersionsPG 16-18 Evidence2 source location(s)

Official description

Waiting while acquiring a contended spinlock

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_SPIN_DELAY at src/backend/storage/lmgr/s_lock.c:148 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:181. The instrumented operation is: Waiting while acquiring a contended spinlock. The SpinDelay path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/SpinDelay 
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 = 'Timeout'
  AND wait_event = 'SpinDelay'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'SpinDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.8 - Timeout: VacuumDelay

Waiting in a cost-based vacuum delay point
PostgreSQL wait event dossier
ClassTimeout EventVacuumDelay VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting in a cost-based vacuum delay point

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

Trigger mechanism

WAIT_EVENT_VACUUM_DELAY at src/backend/commands/vacuum.c:2495 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:182. The instrumented operation is: Waiting in a cost-based vacuum delay point. The VacuumDelay path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/VacuumDelay 
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 = 'Timeout'
  AND wait_event = 'VacuumDelay'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'VacuumDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.9 - Timeout: VacuumTruncate

Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed
PostgreSQL wait event dossier
ClassTimeout EventVacuumTruncate VersionsPG 15-18 Evidence2 source location(s)

Official description

Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_VACUUM_TRUNCATE at src/backend/access/heap/vacuumlazy.c:3280 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:183. The instrumented operation is: Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed. The VacuumTruncate path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/VacuumTruncate 
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 = 'Timeout'
  AND wait_event = 'VacuumTruncate'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'VacuumTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

10.10 - Timeout: WalSummarizerError

Waiting after a WAL summarizer error
PostgreSQL wait event dossier
ClassTimeout EventWalSummarizerError VersionsPG 17-18 Evidence2 source location(s)

Official description

Waiting after a WAL summarizer error

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

Trigger mechanism

WAIT_EVENT_WAL_SUMMARIZER_ERROR at src/backend/postmaster/walsummarizer.c:337 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:184. The instrumented operation is: Waiting after a WAL summarizer error. The WalSummarizerError path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

  • Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
  • Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

Sessions waiting on Timeout/WalSummarizerError 
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 = 'Timeout'
  AND wait_event = 'WalSummarizerError'
ORDER BY query_age DESC NULLS LAST;
Current Timeout 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 = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'WalSummarizerError'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Identify the GUC or function that owns the timer.
  2. Compare productive work with time spent delayed.
  3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

Related controls and signals

11 - BufferPin waits

A backend needs an exclusive buffer pin while another backend still holds one.

BufferPin has one core event, also named BufferPin. It means PostgreSQL needs exclusive access to a shared buffer but another backend still pins that page so it cannot be removed or structurally changed.

Treat persistence as suspicious

Pins are normal and short-lived while executors inspect pages. A sustained exclusive-pin wait is unusual and can come from another session holding a cursor open, an executor paused on a page, or concurrent index work that needs to delete/recycle the page.

  • Normal: isolated, sub-second samples during scans or index maintenance.
  • Watch: the same foreground session remains on BufferPin for more than one second.
  • Urgent: many sessions queue, index cleanup/DDL cannot advance, or a cursor-owning session is idle while holding the pin.

What to inspect

  1. Identify the waiting query and its relation locks.
  2. Look for long-running cursors, idle in transaction, and executor sessions touching the same relation.
  3. Correlate the onset with VACUUM, index deletion/recycling, DDL, or long scans.
  4. Preserve the holder’s query and transaction context before cancelling anything.

Common misreads

  • A buffer pin is not a heavyweight lock and has no direct owner row in pg_locks.
  • shared_buffers size does not make a held pin disappear.
  • The waiter may be vacuum/index maintenance while the application session holding the pin looks harmless.

11.1 - BufferPin: BufferPin

Waiting to acquire an exclusive pin on a buffer
PostgreSQL wait event dossier
ClassBufferPin EventBufferPin VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to acquire an exclusive pin on a buffer

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

Trigger mechanism

WAIT_EVENT_BUFFER_PIN at src/backend/storage/buffer/bufmgr.c:5819 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:286. The instrumented operation is: Waiting to acquire an exclusive pin on a buffer. The buffer manager needs an exclusive pin, but another backend still holds a pin on the same shared buffer. It sleeps until the last conflicting pin is released.

Normal or trouble?

  • Normal: An isolated sub-second sample can occur during scans or index maintenance.
  • Investigate: Treat a wait beyond one second as suspicious, especially when a cursor or idle transaction may keep the page pinned.

Diagnostic SQL

Sessions waiting on BufferPin/BufferPin 
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 = 'BufferPin'
  AND wait_event = 'BufferPin'
ORDER BY query_age DESC NULLS LAST;
Current BufferPin 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 = 'BufferPin'
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 = 'BufferPin'
  AND a.wait_event = 'BufferPin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Preserve the waiting query and relation context.
  2. Find long cursors and idle-in-transaction sessions touching the same relation.
  3. Cancel only after identifying the safest holder or maintenance victim.

Source evidence

Related controls and signals

12 - Extension wait events

How PostgreSQL extensions register and report custom wait-event names, and why they are outside the core catalogue.

PostgreSQL reserves the Extension wait-event type for waits reported by extension code. The built-in inventory contains the generic Extension identity, while newer releases also expose APIs that let extensions register human-readable custom names.

Boundary of this atlas

This site inventories the core names shipped by PostgreSQL 13–18. It does not attempt to enumerate names created at runtime by third-party extensions because that set depends on the loaded binaries and can differ between clusters.

When you see an extension-defined wait:

  1. Record extversion and the exact extension package build.
  2. Query the local pg_wait_events view on PG17+; it is the authority for names registered in that instance.
  3. Search the extension source for its registration call and matching pgstat_report_wait_start() / pgstat_report_wait_end() pair.
  4. Use the extension’s runbook for normal/trouble boundaries; the PostgreSQL core description cannot supply them.
Installed extensions and extension waits 
SELECT e.extname, e.extversion
FROM pg_extension AS e
ORDER BY e.extname;

SELECT type, name, description
FROM pg_wait_events
WHERE type = 'Extension'
ORDER BY name;
Note

pg_wait_events exists in PostgreSQL 17 and later. On PG13–16, identify the wait name from pg_stat_activity and inspect the extension version/source directly.

Safety contract for extension authors

Report the wait immediately before the blocking operation and clear it on every exit path, including errors. Keep the name stable enough for dashboards and runbooks, and document which resource or peer can make progress. A custom name without that ownership contract is observability debt.

13 - Related GUCs

Configuration controls referenced by wait-event response guidance.

Configuration controls referenced by wait-event response guidance. This index contains 21 entries.

13.1 - [[guc:autovacuum_freeze_max_age]]

Transaction age that forces anti-wraparound vacuum.

Transaction age that forces anti-wraparound vacuum.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.2 - [[guc:autovacuum_multixact_freeze_max_age]]

Multixact age that forces anti-wraparound vacuum.

Multixact age that forces anti-wraparound vacuum.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.3 - [[guc:autovacuum_naptime]]

Minimum delay between autovacuum launcher rounds per database.

Minimum delay between autovacuum launcher rounds per database.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.4 - [[guc:checkpoint_timeout]]

Maximum time between automatic WAL checkpoints.

Maximum time between automatic WAL checkpoints.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.5 - [[guc:deadlock_timeout]]

Delay before PostgreSQL checks a lock wait for deadlock.

Delay before PostgreSQL checks a lock wait for deadlock.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.6 - [[guc:full_page_writes]]

Controls full-page images after checkpoints for crash safety.

Controls full-page images after checkpoints for crash safety.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.7 - [[guc:idle_in_transaction_session_timeout]]

Terminates sessions left idle inside an open transaction.

Terminates sessions left idle inside an open transaction.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.8 - [[guc:lock_timeout]]

Aborts statements that wait too long to acquire a lock.

Aborts statements that wait too long to acquire a lock.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.9 - [[guc:max_connections]]

Maximum concurrent database connections.

Maximum concurrent database connections.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.10 - [[guc:max_locks_per_transaction]]

Shared lock-table capacity budget per transaction.

Shared lock-table capacity budget per transaction.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.11 - [[guc:max_parallel_workers_per_gather]]

Maximum parallel workers per Gather/Gather Merge node.

Maximum parallel workers per Gather/Gather Merge node.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.12 - [[guc:max_wal_size]]

Soft WAL-volume limit that can trigger checkpoints.

Soft WAL-volume limit that can trigger checkpoints.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.13 - [[guc:shared_buffers]]

Size of PostgreSQL’s shared buffer cache.

Size of PostgreSQL’s shared buffer cache.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.14 - [[guc:synchronous_commit]]

Controls when commits wait for local or remote WAL durability.

Controls when commits wait for local or remote WAL durability.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.15 - [[guc:synchronous_standby_names]]

Selects standbys that can satisfy synchronous commit.

Selects standbys that can satisfy synchronous commit.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.16 - [[guc:vacuum_freeze_table_age]]

Table age at which VACUUM scans for freezing.

Table age at which VACUUM scans for freezing.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.17 - [[guc:vacuum_multixact_freeze_table_age]]

Table multixact age at which VACUUM scans for freezing.

Table multixact age at which VACUUM scans for freezing.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.18 - [[guc:wal_buffers]]

Shared-memory buffers used for WAL not yet written to disk.

Shared-memory buffers used for WAL not yet written to disk.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.19 - [[guc:wal_sender_timeout]]

Disconnects inactive replication connections after a timeout.

Disconnects inactive replication connections after a timeout.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.20 - [[guc:wal_writer_delay]]

Delay between WAL writer activity rounds.

Delay between WAL writer activity rounds.

Official PostgreSQL 18 parameter reference

Referenced by wait events

13.21 - [[guc:wal_writer_flush_after]]

Amount of WAL written before the WAL writer requests a flush.

Amount of WAL written before the WAL writer requests a flush.

Official PostgreSQL 18 parameter reference

Referenced by wait events

14 - Related metrics

Signals used to decide whether a wait is expected or harmful.

Signals used to decide whether a wait is expected or harmful. This index contains 22 entries.

14.1 - [[metric:active_backends]]

Backends currently executing a query.

Backends currently executing a query.

Referenced by wait events

14.2 - [[metric:blocked_sessions]]

Sessions with one or more blocking PIDs.

Sessions with one or more blocking PIDs.

Referenced by wait events

14.3 - [[metric:blocks_read]]

Relation blocks read by database or statement.

Relation blocks read by database or statement.

Referenced by wait events

14.4 - [[metric:buffer_hit_ratio]]

Blocks served from shared buffers versus blocks read.

Blocks served from shared buffers versus blocks read.

Referenced by wait events

14.5 - [[metric:checkpoint_time]]

Checkpoint write and synchronization duration.

Checkpoint write and synchronization duration.

Referenced by wait events

14.6 - [[metric:commit_latency]]

End-to-end transaction commit latency.

End-to-end transaction commit latency.

Referenced by wait events

14.7 - [[metric:io_read_time]]

Timed read latency from pg_stat_io or operating-system telemetry.

Timed read latency from pg_stat_io or operating-system telemetry.

Referenced by wait events

14.8 - [[metric:io_write_time]]

Timed write latency from pg_stat_io or operating-system telemetry.

Timed write latency from pg_stat_io or operating-system telemetry.

Referenced by wait events

14.9 - [[metric:locks_per_backend]]

Rows in pg_locks grouped by backend.

Rows in pg_locks grouped by backend.

Referenced by wait events

14.10 - [[metric:multixact_member_io]]

Reads and writes for multixact member storage.

Reads and writes for multixact member storage.

Referenced by wait events

14.11 - [[metric:oldest_multixact_age]]

Oldest multixact age that still requires preservation.

Oldest multixact age that still requires preservation.

Referenced by wait events

14.12 - [[metric:oldest_transaction_age]]

Age of the oldest open transaction or visibility horizon.

Age of the oldest open transaction or visibility horizon.

Referenced by wait events

14.13 - [[metric:replication_flush_lag]]

Distance or time between primary WAL and standby flush position.

Distance or time between primary WAL and standby flush position.

Referenced by wait events

14.14 - [[metric:statement_latency]]

Latency distribution for statements associated with the wait.

Latency distribution for statements associated with the wait.

Referenced by wait events

14.15 - [[metric:statement_wal_bytes]]

WAL bytes attributed to statements when pg_stat_statements tracks WAL.

WAL bytes attributed to statements when pg_stat_statements tracks WAL.

Referenced by wait events

14.16 - [[metric:wait_event_share]]

Share of repeated active-session samples attributed to one event.

Share of repeated active-session samples attributed to one event.

Referenced by wait events

14.17 - [[metric:waiting_sessions]]

Current sessions grouped by wait type and event.

Current sessions grouped by wait type and event.

Referenced by wait events

14.18 - [[metric:wal_bytes]]

WAL bytes generated over the observation interval.

WAL bytes generated over the observation interval.

Referenced by wait events

14.19 - [[metric:wal_fpi]]

Full-page images generated in WAL.

Full-page images generated in WAL.

Referenced by wait events

14.20 - [[metric:wal_sync_time]]

Time spent synchronizing WAL to durable storage.

Time spent synchronizing WAL to durable storage.

Referenced by wait events

14.21 - [[metric:wal_write_time]]

Time spent writing WAL.

Time spent writing WAL.

Referenced by wait events

14.22 - [[metric:xact_slru_io]]

Reads and writes for the transaction-status SLRU.

Reads and writes for the transaction-status SLRU.

Referenced by wait events