Re: allowing wal_level change at run time

On Wed, Aug 19, 2015 at 2:46 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
>> 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

Switching archive_mode and wal_level to PGC_SIGHUP would be nice. We
can already faking that by setting archive_command to '/usr/bin/true'
for the first one or similar but that's not really the same as
switching it completely to off.

> 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.

Yes. Those have effects on the shared memory size allocated at
postmaster startup.

> 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.

Or surely max_wal_senders > 0.

> 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.

So, wal_level is automatically bumped to hot_standby when the physical
slot is created (or logical for a logical slot) even if WAL is not
reserved, right? When would those slots be created?

> 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?

Perhaps, craziest ideas are usually worth it :)

At least, we have a couple of things we can consider:
- Make archive_mode SIGHUP
- Remove wal_level and set it as follows:
-- archive/hot_standby if max_wal_sender > 0 (depends surely on
restart) or archive_mode = on (gets more complicated if archive_mode
switches to SIGHUP) at startup.
-- logical should a logical slot be created.
-- If max_wal_senders = 0 and archive_mode = off, switch wal_level to
hot_standby once a physical slot is created.
In short switching archive_mode to SIGHUP has as requirement to get
rid of wal_level first.
Regards,
--
Michael