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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers