warn-replication-lag-risk

What It Detects

WAL-heavy operation on a large table while streaming replicas are connected.

Why It's Dangerous

All of that work goes through WAL, and a standby replays WAL with a single startup process — work the primary spread across many backends arrives at the replica serially, so lag grows for as long as the operation runs and for some time after. If any reads are served from replicas they serve stale data for that whole window, and a failover while lag is high loses whatever has not been replayed. Replication slots turn the pressure around: if a replica cannot keep up, the primary keeps WAL for it until the disk fills.

Bad Example

-- events is 60 GB, two streaming replicas connected
UPDATE events SET processed = true WHERE processed IS NULL;

Good Example

-- Batch the work, and let replicas catch up between batches:
DO $$
DECLARE
  rows_updated INT;
BEGIN
  LOOP
    UPDATE events SET processed = true
    WHERE ctid IN (
      SELECT ctid FROM events WHERE processed IS NULL LIMIT 10000
    );
    GET DIAGNOSTICS rows_updated = ROW_COUNT;
    EXIT WHEN rows_updated = 0;
    COMMIT;
    PERFORM pg_sleep(0.5);
  END LOOP;
END $$;

Configuration

Disable this rule:

# .migrationpilotrc.yml
rules:
  MP103: false

Or change its severity:

# .migrationpilotrc.yml
rules:
  MP103:
    severity: warning