Re: allowing wal_level change at run time

On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
> On 8/18/15 12:35 PM, Robert Haas wrote:
> > If archive_mode=on or max_wal_senders>0, then we need at least
> > wal_level=archive. Otherwise wal_level=minimal is enough.
>
> Totally forgot about max_wal_senders.
>
> However, the thread I linked to earlier aimed for a different master
> plan (or if not, I'm aiming for it now). There is camp 1, which wants
> to keep all the defaults the same, for "performance" or something like
> that. And there is camp 2, which wants to have a replication-friendly
> setup by default. Instead of fighting over this, your idea was to be
> able to switch between 1 and 2 easily (which means in particular without
> restarts).

I don't think not requiring restarts is sufficient, having to twiddle a
bunch of parameters manually still is a lot more effort than people see
as necessary.

The only reason I think changing the default is a good approach is that
it's doable within a relatively short amount of time.

> But if we tie the effective wal_level to archive_mode or
> max_wal_senders, both of which are restart-only, then we haven't gained
> anything. (We would have removed half a GUC parameter, effectively.
> Not bad, but not very exciting.)

ISTM that it's not too hard to
a) make archive_mode PGC_SIGHUP
b) make wal_level PGC_SIGHUP
c) automatically increase wal_level to logical whenever a logical
replication slot is defined

it seems considerably harder to

d) make max_wal_senders PGC_SIGHUP
e) make max_replication_slots PGC_SIGHUP

because they need shmem, locks, and everything.

Therefore I propose something slightly different:

We change the default of max_wal_senders, max_replication_slots, to some
reasonably high setting and make wal_level an internal automagically
determined variable. archive_mode = on automatically increases the level
to what's now hot-standby.

To deal with streaming replication, we automatically create slots for
replicas, but, by default, *without* having them reserve WAL. The slot
name would be determined in some automatic fashion (uuid or something)
and stored in a new file in the data directory. That allows us to
increase the internal wal_level to hot_standby/archive whenever a
replica has connected (and thus a physical slot exists), and to logical
whenever a logical slot exists.

Now, that'll mean that the wal_level doesn't decrease automatically
until a slot has been dropped. But that seems relatively harmless if
it's not reserving WAL.

Too crazy?

Greetings,

Andres Freund