On 23 March 2017 at 07:31, Andres Freund <and...@anarazel.de> wrote: > On 2017-03-23 06:55:53 +0800, Craig Ringer wrote:
>> I was thinking that by disallowing snapshot use and output plugin >> invocation we'd avoid the need to support cancellation on recovery >> conflicts, etc, simplifying things considerably. > > That seems like it'd end up being pretty hacky - the likelihood that > we'd run into snapbuild error cross-checks seems very high. TBH I'm not following this. But I haven't touched snapbuild much yet, Petr's done much more with snapbuild than I have. We're not going to have robust logical replication that's suitable for HA and failover use on high load systems until 2020 or so, with Pg 12. We'll need concurrent decoding and apply, which nobody's even started on AFAIK, we'll need sequence replication, and more. So I'd really, really like to get some kind of HA picture other than "none" in for logical decoding based systems. If it's imperfect, it's still something. I wish we'd just proceeded with failover slots. They were blocked in favour of decoding on standby, and HA is possible if we have decoding on standby with some more work by the application. But now we'll have neither. If we'd just done failover slots we could've had logical replication able to follow failover in Pg 10. What do _you_ see as the minimum acceptable way to achieve the ability for a logical decoding client to follow failover of an upstream to a physical standby? In the end, you're one of the main people whose view carries weight in this area, and I don't want to develop yet another approach only to have it knocked back once the work is done. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
