Re: Bump default wal_level to logical - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Bump default wal_level to logical
Date
Msg-id CAA4eK1J0we5qsZ-ZOwXPbZyvwdWbnT43knO2Cxidia2aHxZSJw@mail.gmail.com
Whole thread Raw
In response to Re: Bump default wal_level to logical  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Bump default wal_level to logical
Next
From: Ashutosh Bapat
Date:
Subject: pg_dump and concurrent DDL activity