Database Operations
PostgreSQL Replication Lag Debugging Guide
Diagnose PostgreSQL replication lag by separating WAL generation, transport, replay, slot retention and standby resource pressure. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Measure each stage | Compare sent, written, flushed and replayed positions instead of relying on one lag number. |
| Check WAL transport | Inspect network stability, sender state and receiver logs for interruptions. |
| Inspect replay pressure | Long queries, recovery conflicts, storage latency and CPU saturation can delay apply. |
| Review retention | Replication slots and archive failures can grow storage while a standby is unavailable. |
Starter snippet
SELECT application_name, state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication;Review checks
- Record byte lag and time lag together.
- Monitor slot retained WAL volume.
- Test failover readiness separately from streaming state.
- Keep clocks synchronized across nodes.
Common mistakes
- Restarting the standby before collecting LSN evidence.
- Treating an idle primary as proof replication recovered.
- Dropping a slot without confirming consumer ownership.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Postgresql Dba Checklist, Postgresql Connection Limit Guide, Postgresql Lock Debugging Guide.