On 2015-12-15 13:17, Andres Freund wrote:
> On 2015-12-14 16:19:33 +0800, Craig Ringer wrote:
>
>> Needed to make logical replication based failover possible.
>
> While it'll make it easier, I think it's certainly quite possible to do
> so without this feature if you accept some sane restrictions. If you
> e.g. define to only handle serial columns (i.e. sequences that
> used/owned by exactly one table & column), you can do a 'good enough'
> emulation the output plugin.
>
> Take something like BDR's bdr_relcache.c (something which you're going
> to end up needing for any nontrivial replication solution). Everytime
> you build a cache entry you look up whether there's an owned by
> sequence. When decoding an insert or update to that relation, also emit
> an 'increase this sequence to at least XXX' message.
>
> While it's not perfect, this has the big advantage of being doable with 9.4.
>
I don't think that approach alone is good enough. It might be ok for
selective replication where the replication is driven by tables anyway,
but in general and especially for failover it's not good enough to tell
user that we handle some sequences and they have to fix the rest
manually. That's not much different than fixing them all in practice as
you script it anyway.
However, if it was combined with something like what londiste does,
which is to check sequences periodically and send last_value + some
reasonable buffer, it could work well in most cases. In this scenario
your method would be used for checking that sequence is close to going
over buffer and firing the periodic send sooner than it would be if it
was purely time based.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
