Section 2 of 3 · 6 minutes
Find what is slowing replay
Your goal
What you will be able to do
Check standby receive state, replay state, conflicts, storage pressure, and retained WAL before intervening.
Why this matters at work
The practical reason
Restarting replication without locating the slow stage can discard evidence and repeat the same delay.
Learn
The idea in plain English
On the standby, inspect `pg_stat_wal_receiver`, recovery state, last replay time, storage latency, and query conflicts. Long read queries can conflict with replay when cleanup records must be applied.
On the primary, confirm the sender is connected and enough WAL remains available. A failed slot or missing WAL may require rebuilding the standby rather than a simple restart.
Remember these points
- Inspect both sides of the replication link.
- Separate transport, storage, replay, and query-conflict causes.
- Confirm required WAL still exists before reconnecting.
See it in SQL
Read standby receiver state
Confirm where the standby receives WAL and its latest received position.
SELECT
status,
sender_host,
sender_port,
slot_name,
written_lsn,
flushed_lsn,
latest_end_lsn,
latest_end_time
FROM pg_stat_wal_receiver;A healthy streaming standby normally shows one receiver row. Missing or stale values direct the investigation toward connection or source availability.
Treat host and slot names as operational metadata; do not expose them on public credential pages.
The active WAL receiver's source, slot, status, and latest received and flushed positions.
Useful words
Important terms
- WAL receiver
- The standby process that receives streamed WAL from a primary.
Quick check · Not graded
Check your understanding
Where should replication-lag evidence be collected?
Your progress is saved to your signed-in account.