MIME-Version: 1.0
References: <20190523160023.cpi7cyozbthflx32@alap3.anarazel.de>
 <20190611183650.GA25310@alvherre.pgsql>
In-Reply-To: <20190611183650.GA25310@alvherre.pgsql>
From: Amit Khandekar <amitdkhan.pg@gmail.com>
Date: Fri, 14 Jun 2019 17:07:05 +0530
Message-ID: 
 <CAJ3gD9dPM-6NPMKujsq9BOiLGfYzOUZxmD0mJWV6WL6wY9+FAQ@mail.gmail.com>
Subject: Re: Minimal logical decoding on standbys
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
	Sergei Kornilov <sk@zsrv.org>, tushar <tushar.ahuja@enterprisedb.com>,
	Petr Jelinek <petr.jelinek@2ndquadrant.com>,
 Craig Ringer <craig@2ndquadrant.com>,
	Petr Jelinek <petr@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 12 Jun 2019 at 00:06, Alvaro Herrera <alvherre@2ndquadrant.com> wro=
te:
>
> On 2019-May-23, Andres Freund wrote:
>
> > On 2019-05-23 09:37:50 -0400, Robert Haas wrote:
> > > On Thu, May 23, 2019 at 9:30 AM Sergei Kornilov <sk@zsrv.org> wrote:
> > > > > wal_level is PGC_POSTMASTER.
> > > >
> > > > But primary can be restarted without restart on standby. We require=
 wal_level replica or highter (currently only logical) on standby. So onlin=
e change from logical to replica wal_level is possible on standby's control=
file.
> > >
> > > That's true, but Amit's scenario involved a change in wal_level durin=
g
> > > the execution of pg_create_logical_replication_slot(), which I think
> > > can't happen.
> >
> > I don't see why not - we're talking about the wal_level in the WAL
> > stream, not the setting on the standby. And that can change during the
> > execution of pg_create_logical_replication_slot(), if a PARAMTER_CHANGE
> > record is replayed. I don't think it's actually a problem, as I
> > outlined in my response to Amit, though.
>
> I don't know if this is directly relevant, but in commit_ts.c we go to
> great lengths to ensure that things continue to work across restarts and
> changes of the GUC in the primary, by decoupling activation and
> deactivation of the module from start-time initialization.  Maybe that
> idea is applicable for this too?

We do kind of handle change in wal_level differently at run-time
versus at initialization. E.g. we drop the existing slots if the
wal_level becomes less than logical. But I think we don't have to do a
significant work unlike how it seems to have been done in
ActivateCommitTs when commit_ts is activated.

>
> --
> =C3=81lvaro Herrera                https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company