From: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Minimal logical decoding on standbys |
Date: | 2019-04-16 06:57:46 |
Message-ID: | CAJ3gD9fNuB9hTBMmQ=k9Be0LmPVEPwb8nv-5jc=fbgxUn=82Vw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 13 Apr 2019 at 00:57, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2019-04-12 23:34:02 +0530, Amit Khandekar wrote:
> > I tried to see if I can quickly understand what's going on.
> >
> > Here, master wal_level is hot_standby, not logical, though slave
> > wal_level is logical.
>
> Oh, that's well diagnosed. Cool. Also nicely tested - this'd be ugly
> in production.
Tushar had made me aware of the fact that this reproduces only when
master wal_level is hot_standby.
>
> I assume the problem isn't present if you set the primary to wal_level =
> logical?
Right.
>
>
> > Not sure why this is happening. On slave, wal_level is logical, so
> > logical records should have tuple data. Not sure what does that have
> > to do with wal_level of master. Everything should be there on slave
> > after it replays the inserts; and also slave wal_level is logical.
>
> The standby doesn't write its own WAL, only primaries do. I thought we
> forbade running with wal_level=logical on a standby, when the primary is
> only set to replica. But that's not what we do, see
> CheckRequiredParameterValues().
>
> I've not yet thought this through, but I think we'll have to somehow
> error out in this case. I guess we could just check at the start of
> decoding what ControlFile->wal_level is set to,
By "start of decoding", I didn't get where exactly. Do you mean
CheckLogicalDecodingRequirements() ?
> and then raise an error
> in decode.c when we pass an XLOG_PARAMETER_CHANGE record that sets
> wal_level to something lower?
Didn't get where exactly we should error out. We don't do
XLOG_PARAMETER_CHANGE handling in decode.c , so obviously you meant
something else, which I didn't understand.
What I am thinking is :
In CheckLogicalDecodingRequirements(), besides checking wal_level,
also check ControlFile->wal_level when InHotStandby. I mean, when we
are InHotStandby, both wal_level and ControlFile->wal_level should be
>= WAL_LEVEL_LOGICAL. This will allow us to error out when using logical
slot when master has incompatible wal_level.
ControlFile is not accessible outside xlog.c so need to have an API to
extract this field.
>
> Could you try to implement that?
>
> Greetings,
>
> Andres Freund
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-04-16 06:57:59 | Re: [PATCH v20] GSSAPI encryption support |
Previous Message | Peter Eisentraut | 2019-04-16 06:55:05 | Re: Commit message / hash in commitfest page. |