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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
