Re: [PATCH] Logical decoding support for sequence advances
От | Petr Jelinek |
---|---|
Тема | Re: [PATCH] Logical decoding support for sequence advances |
Дата | |
Msg-id | 56700BA5.9080300@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Logical decoding support for sequence advances (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Logical decoding support for sequence advances
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: