On Tue, Jun 9, 2020 at 6:57 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Jun 9, 2020 at 3:02 AM Andres Freund <and...@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
