Re: allowing wal_level change at run time

On 8/18/15 1:46 PM, Andres Freund wrote:
> 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.

I agree that we want both. But requiring a restart is a hard stop,
whereas making configuration easier is a soft feature.

> ISTM that it's not too hard to
> a) make archive_mode PGC_SIGHUP

That has been contentious in the past, but I would agree that it seems
that it should be doable. (I consider archiving a legacy feature at
this point, so for this purpose I don't really care whether it's possible.)

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

check

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

check

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

That seems kind of weird. So every time a replication client connects,
we create a new replication slot? Won't they accumulate? Do we need
the replication slot, or could we just trigger this on the existence of
a replication client?

Also note that this scheme and any similar one requires merging the
archive and hot_standby levels, which was the core of your original
proposal [1], which was then objected to, which subsequently lead to
Robert's proposal to make wal_level SIGHUP, which lead to my message,
which lead to your message, which is similar to your initial one.
Somehow we have to find a way break out of this circle. ;-)

[1]
http://www.postgresql.org/message-id/20150203124317.GA24767@awork2.anarazel.de