Re: allowing wal_level change at run time

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 8/18/15 8:48 AM, Robert Haas wrote:
>> What do you mean by "prevent"? If the user edits postgresql.conf and
>> reduces the setting, and then reloads the configuration file, they
>> have a right to expect that the changes got applied.

> We have certain checks in place that require a minimum wal_level before
> other things are allowed. For example, turning on archiving requires
> wal_level >= archive. The issue is then, if you have archiving on and
> then turn wal_level to minimal at run time, we need to prevent that to
> preserve the integrity of the original check.

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

IOW: let's simplify, not complicate even further. Try to get rid of
the interdependencies between settable parameters.

regards, tom lane