The one thing to understand first
A replica (physical standby or logical subscriber) consumes WAL from the primary. If the primary recycles WAL before the replica has read it, the replica falls irrecoverably behind and must be rebuilt. The old wal_keep_size approach — keep a fixed amount of WAL and hope it’s enough — is fragile. Replication slots solve this precisely by tracking exactly how far each consumer has progressed and retaining WAL until then.
A slot is a promise the primary makes to a consumer: “I will keep this WAL until you read it.” The catch is that the promise has no expiry — make it to a consumer that never returns and it becomes a promise to fill your own disk.
How a slot works
A slot (src/backend/replication/slot.c) is a named, persistent marker recording the oldest WAL position (restart_lsn) a consumer still needs. The primary will not remove WAL beyond that position. Slots survive restarts, so a standby can disconnect, come back hours later, and resume from exactly where it stopped — no rebuild required.