Client: WaitForStandbyConfirmation
Waiting for WAL to be received and flushed by the physical standby
PostgreSQL wait event dossier
ClassClient
Event
WaitForStandbyConfirmation
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
Current Client cohort
Lock and relation context for these sessions
Response
- Check state and transaction age before counting the wait as load.
- Correlate with the owning application, pool, and network path.
- Fix consumer backpressure or pool policy rather than repeatedly terminating connections.
Source evidence
- PostgreSQL 18.6 · src/backend/replication/slot.c:3083 —
WAIT_EVENT_WAIT_FOR_STANDBY_CONFIRMATION - PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:91 —
WAIT_FOR_STANDBY_CONFIRMATION
Related controls and signals
- GUCs: [guc:max_connections] · [guc:idle_in_transaction_session_timeout]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:active_backends]