LWLock: SyncRep
Waiting to read or update information about the state of synchronous replication
PostgreSQL wait event dossier
ClassLWLock
Event
SyncRep
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
Current LWLock cohort
Lock and relation context for these sessions
Response
- Separate LWLock/SyncRep from IPC/SyncRep and replication-lag waits.
- Inspect synchronous standby health, sender churn, and commit rate.
- Stabilize replication and smooth commit bursts; change durability policy only with explicit incident authority.
Source evidence
- PostgreSQL 18.6 · src/backend/replication/syncrep.c:192 —
SyncRep - PostgreSQL 18.6 · src/backend/storage/lmgr/lwlock.c:739 —
pgstat_report_wait_start - PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:337 —
SyncRep
Related controls and signals
- GUCs: [guc:synchronous_standby_names] · [guc:synchronous_commit] · [guc:wal_sender_timeout]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:replication_flush_lag] · [metric:commit_latency]
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.