2026-09-28 · 6 min read · Rahul Chitturi
- sql
- postgresql
- replication
A PostgreSQL logical replication slot preserves the WAL needed by a consumer and tracks how far that consumer has confirmed. If the consumer stops advancing, retained WAL can fill storage even when database traffic otherwise looks normal.
A slot is durable state with database, plugin, timeline, and consumer assumptions. Restarting an application without understanding those assumptions can cause duplicates, gaps, or a second abandoned slot.
Capture slot and consumer identity
Record the cluster, database, slot name, plugin, publication, subscriber or connector identity, active PID, restart LSN, confirmed flush LSN, current WAL LSN, and observation time. Compare byte lag and time lag; either alone can hide risk.
- Verify the consumer is attached to the intended slot.
- Check that required tables belong to the publication.
- Separate an inactive slot from a slow active consumer.
- Inspect storage headroom before experimenting.
Diagnose why acknowledgement stopped
Trace from WAL generation through decoding, network delivery, downstream processing, checkpoint persistence, and feedback to PostgreSQL. Schema changes, missing replica identity, plugin incompatibility, poison events, unavailable sinks, or a lost consumer checkpoint can all stop advancement.
Do not drop or advance a slot merely to clear disk pressure. Either action can discard changes the consumer still needs. First establish the recovery point and whether the downstream system can rebuild from a trusted snapshot.
Rehearse recovery with disposable data
Use Flashman's SQL formatter for slot diagnostics, timestamp converter for lag timelines, JSON formatter for sanitized decoded events, and diff for consumer checkpoints.
Test consumer restart, transaction bursts, publication changes, replica identity errors, network loss, sink backpressure, plugin upgrades, primary failover, slot invalidation, duplicate delivery, snapshot rebuild, and storage alerts.