From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>, Thom Brown <thom(at)linux(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logical decoding on standby |
Date: | 2017-03-23 01:39:45 |
Message-ID: | 20170323013945.gnyubzikvbtxp7cp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-23 09:14:07 +0800, Craig Ringer wrote:
> On 23 March 2017 at 07:31, Andres Freund <andres(at)anarazel(dot)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 can't just assume that snapbuild is going to work correctly when it's
prerequisites - pinned xmin horizon - isn't working.
> 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.
These seem largely unrelated to the topic at hand(nor do I agree on all
of them).
> 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 still think decoding-on-standby is simply not the right approach as
the basic/first HA approach for logical rep. It's a nice later-on
feature. But that's an irrelevant aside.
I don't understand why you're making a "fundamental" argument here - I'm
not arguing against the goals of the patch at all. I want as much stuff
committed as we can in a good shape.
> 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
I think your approach here wasn't that bad? There's a lot of cleaning
up/shoring up needed, and we probably need a smarter feedback system. I
don't think anybody here has objected to the fundamental approach?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-03-23 01:40:49 | Re: [PATCH] Transaction traceability - txid_status(bigint) |
Previous Message | Amit Langote | 2017-03-23 01:34:40 | Re: UPDATE of partition key |