Why this problem matters
Replication lag can originate in the network, standby I/O, replay load, or long-running queries. A byte difference does not directly equal user-visible time lag.
How to diagnose it
Compare sent_lsn, write_lsn, flush_lsn, and replay_lsn stages on the primary. Do not interpret write_lag, flush_lag, and replay_lag as continuously updated queue sizes.
The query shows primary-side WAL sender state and approximate byte gaps between stages. A disconnected standby does not appear in this view.
SELECT application_name, client_addr, state, sync_state,
pg_wal_lsn_diff(sent_lsn, write_lsn) AS send_write_bytes,
pg_wal_lsn_diff(write_lsn, flush_lsn) AS write_flush_bytes,
pg_wal_lsn_diff(flush_lsn, replay_lsn) AS flush_replay_bytes,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication
ORDER BY application_name;A safe solution approach
After locating the lag stage, target network, storage, CPU, or standby query load. Avoid hiding the root cause by merely increasing a general threshold.
Why continuous monitoring matters
moon helps continuously monitor replication stages with low overhead. Slack, PagerDuty, and webhook alerts route persistent or growing lag to on-call staff.
Frequently asked questions
Does a null replay_lag mean replication is broken?
No, the field depends on activity and measurement conditions and may be null. Use LSN differences, connection state, and standby observations together.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.