At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut <peter.eisentraut@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