On Jul16, 2011, at 20:55 , Tom Lane wrote:
>> The original argument for the current behavior was to avoid applying
>> settings from a thoroughly munged config file, but I think that the
>> checks involved in steps 1-3 would be sufficient to reject files that
>> had major problems. It's possible that step 1 is really sufficient to
>> cover the issue, in which case we could drop the separate step-3 pass
>> and just treat invalid GUC names as a reason to ignore the particular
>> line rather than the whole file. That would make things simpler and
>> faster, and maybe less surprising too.
>
> IOW, I'm now pretty well convinced that so long as the configuration
> file is syntactically valid, we should go ahead and attempt to apply
> each name = value setting individually, without allowing the invalidity
> of any one name or value to prevent others from being applied.
One benefit of this would be that it'd make the logic of ProcessConfigFile
and its interaction with set_config_option() much simpler, and the behaviour
more predictable. Given that it took me a while to work through the
interactions of these two functions, I all for that.
On the downside, the current behaviour prevents problems if someone changes
two interrelated GUCs, but makes a mistake at one of them. For example,
someone might drastically lower bgwriter_delay but might botch the matching
adjustment of bgwriter_lru_maxpages.
Not sure if that out-weights the benefits, but I thought I'd bring it up.
best regards,
Florian Pflug