The one thing to understand first
A replication slot is the bookmark that tells the primary how far a consumer has read and therefore which WAL it must keep. The catch that bit teams for years: slots existed only on the primary. Promote a standby and every logical replication slot vanished with the old primary — so every logical subscriber or change-data-capture consumer lost its position and had to be re-seeded, risking gaps or duplicates. PostgreSQL 17 fixes this with failover slots: a logical slot can be marked to survive failover, and the standby keeps a synchronized copy so the new primary already has the bookmark at a safe position.
This extends Pathway 04’s replication-slots and automatic-failover lessons by closing the gap they leave open: what happens to logical slots when the primary role actually moves.
The mechanism: marking a slot to survive
You opt a logical slot into failover when you create it — pg_create_logical_replication_slot(..., failover := true), or CREATE SUBSCRIPTION ... WITH (failover = true). That sets the failover flag you can see in pg_replication_slots. On its own that flag does nothing; it’s a declaration that this slot is important enough to be mirrored onto the failover-target standby.