On Tue, Aug 18, 2015 at 9:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.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.
Mmm, I like that idea. If we can do it, it seems much cleaner that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
