At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote in > On 2020-06-08 23:32, Andres Freund wrote: > > 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. > > The best behavior from a user's perspective would be if the WAL level > automatically switched to logical if logical replication slots are > present. You might not even need 'logical' as an actual value of > wal_level anymore, you just need to keep a flag in shared memory that > records whether at least one logical slot exists.
Currently logical slots cannot be created while wal_level < logical. Thus a database that has a logical slot must have been once executed with wal_level >= logical before the creation of the slot. It seems to me setting wal_level = logical would be better than creating a dummy logical slot while initdb.. Coulnd't we add an option to speicfy wal_level for initdb? Or an option to append arbitrary config lines to postgresql.conf? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
