Re: allowing wal_level change at run time

On 8/18/15 9:50 AM, Tom Lane wrote:
> IIRC, the reason for having a wal_level parameter separate from those
> other ones was precisely that only wal_level had to be PGC_POSTMASTER,
> and you could change the others if you wanted.

I think you are thinking of having split archive_mode/archive_command,
so you can change archive_command at run time.

> If we are going to fix
> the mechanisms to allow dynamic changing in wal log verbosity, maybe
> we could simply get rid of wal_level as a user-settable parameter, and
> have its effective value be inferred from the active settings of the
> other parameters.

That would be nice, but those "other parameters" aren't really things
that we can easily look at. In the old days, you could say that
archive_mode = on was a pretty sure sign that you'd need wal_level =
archive, but nowadays you can run replication without archiving. We
could dial wal_level up and down every time someone connects to stream
WAL, but that would surely lead to complications. Also, we have no way
of knowing whether someone needs wal_level hot_standby until the WAL is
on the standby and the standby decides to set hot_standby = on. The
permutations of what could possibly influence this setting are quite
enormous, if you consider archiving, streaming, hot standby, hot standby
feedback, replication slots, etc., and synchronizing all of that sounds
like a mess.