On Tue, Aug 18, 2015 at 9:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
