Logical replication lag bulk update
You run logical replication from your primary Postgres to a separate analytics/CDC target. Suddenly the subscriber falls hours behind: the downstream warehouse is stale, lag on the slot grows monotonically, and WAL is starting to accumulate on the primary (raising disk concern). The primary's own OLTP traffic looks normal. Earlier today a maintenance job ran a single `UPDATE` that touched ~80M rows in one transaction on a heavily-replicated table. Triage and mitigate.
What a strong answer looks like
Stop the bleeding first (mitigate), then form hypotheses from real signals. Separate root cause from symptom, communicate status as you go, and close with what prevents a repeat.
0:00 of about 35 min
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.