On Tue, Jun 9, 2020 at 6:57 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Jun 9, 2020 at 3:02 AM Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> > > If we can allow wal_level to be changed on the fly, I agree that would
> > > help reduce the pressure to make the default setting more expensive.
> > > I don't recall why it's PGC_POSTMASTER right now, but I suppose there
> > > was a reason for that ...
> >
> > There's reasons, but IIRC they're all solvable with reasonable effort. I
> > think most of it boils down to only being able to rely on the new
> > wal_level after a while. For minimal->recovery we basically need a
> > checkpoint started after the change in configuration, and for
> > recovery->logical we need to wait until all sessions have a) read the
> > new config setting b) finished the transaction that used the old
> > setting.
> >
>
> What if we note down the highest transaction id when we set wal_level
> = logical and won't allow a snapshot in logical decoding to reach a
> consistent state till we see at least that xid as committed? I think
> this will mean that it won't allow to decode any transaction which is
> operated with wal_level < logical and that might serve the purpose.
>
I intend to say that if the above is possible then we don't need to
wait for (b).
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com