Re: WIP: Failover Slots - Mailing list pgsql-hackers

 

I think it's the most sensible default if there's only going to be one choice to start with. It's consistent with what we do elsewhere with replicas so there won't be any surprises.   Failover slots are a fairly simple feature that IMO just makes slots behave more like you might expect them to do in the first place.

I'm pretty hesitant to start making cascaded replicas different to each other just for slots. There are lots of other things where variation between replicas would be lovely - the most obvious of which is omitting some databases from some replicas. Right now we have a single data stream, WAL, that goes to every replica. If we're going to change that I'd really like to address it in a way that'll meet future needs like selective physical replication too. I also think we'd want to deal with the problem of identifying and labeling nodes to do a good job of selective replication of slots.

I'd like to get failover slots in place for 9.6 since the're fairly self-contained and meet an immediate need: allowing replication using slots (physical or logical) to follow a failover event.

After that I want to add logical decoding support for slot creation/drop/advance. So a logical decoding plugin can mirror logical slot state on another node. It wouldn't be useful for physical slots, of course, but it'd allow failover between logical replicas where we can do cool things like replicate just a subset of DBs/tables/etc. (A mapping of upstream to downstream LSNs would be required, but hopefully not too hard). That's post-9.6 work and separate to failover slots, though dependent on them for the ability to decode slot changes from WAL.

Down the track I'd very much like to be less dependent on forcing everything though WAL with a single timeline. I agree with Andres that being able to use failover slots on replicas would be good, and that it's not possible when we use WAL to track the info. I just think it's a massive increase in complexity and scope and I'd really like to be able to follow failover the simple way first, then enhance it.

Nothing stops us changing failover slots in 9.7+ from using WAL to some other mechanism that we design carefully at that time. We can extend the walsender command set for physical rep at a major version bump with no major issues, including adding to the streaming rep protocol. There's lots to figure out though, including how to maintain slot changes in a strict ordering with WAL, how to store and read the info, etc.