Replication Lag

Overview

Replication lag measures how far behind a standby server is from the primary. For streaming replication, insightral tracks write_lag, flush_lag, and replay_lag. For logical replication slots, it tracks the volume of WAL retained on disk waiting to be consumed. Both types of lag matter: streaming lag means reads from the replica are stale, while slot lag means the primary cannot recycle WAL, eventually filling the disk.

An inactive or abandoned replication slot is particularly dangerous because it silently retains WAL indefinitely. insightral flags both lag > 30 seconds on streaming replicas and replication slots retaining > 1 GB of WAL as findings.

Detection SQL

Run this query with a read-only role. No writes, no locks.

-- Streaming replication lag per standby
SELECT
  application_name,
  client_addr,
  state,
  sent_lsn,
  write_lsn,
  flush_lsn,
  replay_lsn,
  write_lag,
  flush_lag,
  replay_lag,
  sync_mode,
  sync_state
FROM pg_stat_replication
ORDER BY replay_lag DESC NULLS LAST;

-- Replication slot lag (retained WAL)
SELECT
  slot_name,
  plugin,
  slot_type,
  active,
  pg_size_pretty(
    pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
  ) AS retained_wal
FROM pg_replication_slots
ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC;

Fix SQL

Replace placeholders in <angle brackets> with values from the detection output before running.

-- For a stalled logical replication slot consuming disk, drop if safe
SELECT pg_drop_replication_slot('<slot_name>');

-- For streaming lag from a standby under load, check standby's
-- max_standby_streaming_delay and wal_receiver_timeout settings.
-- On the primary, check wal_keep_size is large enough.

Worked example

Common false positives

• Expected replica lag during planned maintenance windows where the standby is intentionally paused.
• Logical replication slots used by active Debezium or pglogical instances will always show some retained WAL — the threshold is the concern, not the existence of the slot.