On 2016-04-05 05:53:53 +0200, Petr Jelinek wrote: > On 04/04/16 17:15, Andres Freund wrote: > > > >>* Robust sequence decoding and replication. If you were following the later > >>parts of that discussion you will've seen how fun that's going to be, but > >>it's the simplest of all of the problems. > > > >Unconvinced. People used londiste and slony for years without that, and > >it's not even remotely at the top of the list of problems with either. > > > > Londiste and Slony also support physical failover unlike logical decoding > which is the main point of this discussion, lets not forget that.
Sure. But that level of failover isn't all that hard to implement.
Well, they get it mostly for free. Because they work at the SQL level and we have working physical failover, so they don't really notice the change.
Just like I've been trying to make possible for logical decoding and logical replication.
> If we got failover slots into 9.6 it would > be better but that does not look realistic at this point. I don't think that > current design for failover slots is best possible - I think failover slots > should be created on replica and send their status up to the master which > would then take them into account when calculating oldest needed catalog > xmin and lsn (simple way of doing that would be to add this to feedback > protocol and let physical slot to keep the xmin/lsn as well)
Yes, that's not too far away from what I'm thinking of. If we do it right that also solves the important problems for decoding on a standby.
I'm pretty happy with this approach too.
It puts a bit more burden on the client, but I think that can be solved separately and later with a helper running on the replica.
I've never liked how failover slots can't work with a cascading replica when we get support for that. By contrast, this approach would actually help solve one of the problems needed to get replay from a replica working.