hesela.devReplication slot
In PostgreSQL, a replication slot tracks a consumer's progress and retains WAL and other resources needed for that consumer to continue.
Physical and logical slots serve different replication streams. Retention can outlive a disconnected consumer and exhaust WAL storage; the slot is not a synchronous-commit policy. [1] PostgreSQL 18 applies max_slot_wal_keep_size at checkpoints; -1 permits unlimited slot retention, while a finite limit can sacrifice required history. [2] The xmin and catalog_xmin horizons can hold back row-version cleanup independently of WAL byte headroom. [4]
Relations
- related
- asynchronous-replication, synchronous-replication, replication-lag, logical-decoding, write-ahead-log, wal-archiving
Limitations
- A slot is not an independently stored backup and does not establish that a replica has applied a transaction; this is a distinction between retention and acknowledgement contracts. [1, 3]
- Old slot horizons can contribute to transaction-ID exhaustion; PostgreSQL may refuse new XID-assigning work, and removing a still-needed slot can require rebuilding the replica. [5]