2026-09-28 · 8 min read
- sql
- postgresql
- replication
A logical replication slot gives one consumer a durable position in PostgreSQL's write-ahead log. The server retains WAL needed from the slot's restart position, while the confirmed flush position reflects data the consumer has acknowledged.
Slots support change-data capture and logical replication, but they trade recoverability for storage responsibility. An abandoned or stalled slot can retain enough WAL to exhaust the primary's disk.
Assign one owner and one purpose
Document the slot name, database, output plugin, publication, consuming service, deployment environment, responsible team, downstream checkpoint, and removal procedure. A slot should not be casually shared by independent consumers with different acknowledgement needs.
- Use stable environment-specific names.
- Provision and remove slots through reviewed automation.
- Restrict replication privileges.
- Alert when ownership metadata becomes stale.
Budget retained WAL explicitly
Measure retained bytes from the relevant LSNs and compare them with current free storage, WAL generation rate, and the longest supported outage. Alert on absolute bytes, rate of growth, inactivity, and distance from the storage safety margin.
Configure version-appropriate retention limits as a final guardrail, understanding that invalidating a slot protects the database by forcing consumer recovery. A limit is not a replacement for timely alerts and an owned runbook.
Coordinate processing and acknowledgement
The consumer should persist its downstream outcome and source position so it can resume deterministically. Acknowledge only after the required sink effect is durable, and make that effect idempotent because crashes can replay transactions around the checkpoint boundary.
Preserve transaction boundaries and ordering required by the business model. Large transactions, slow sinks, and poison records need bounded handling that does not silently advance past unprocessed changes.
Plan schema changes and failover
Define how publication membership, replica identity, table rewrites, DDL, plugin versions, and application rollouts are coordinated. Logical decoding does not automatically turn every schema evolution into a backward-compatible downstream event.
Document the deployed PostgreSQL version's slot behavior during primary failover and upgrades. Test whether slot state is available and sufficiently current on the promoted server; otherwise use a trusted checkpoint and snapshot procedure.
Rehearse recovery before storage pressure
Use Flashman's SQL formatter for monitoring queries, timestamp converter for lag histories, JSON formatter for synthetic events, diff for checkpoints, and unit converter for WAL budgets.
Test inactive and slow consumers, transaction bursts, network partitions, sink outages, malformed events, missing replica identity, publication changes, plugin upgrades, failover, invalidated slots, duplicates, snapshot rebuilds, disk alerts, and controlled retirement.