Re: Incorrectly reporting config errors

On 2014-01-22 12:10:30 -0500, Tom Lane wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> > My preference would be to not generate noise for interim states;
> > just report net changes.
>
> Yeah. Is it worth explicitly detecting and dropping redundant assignments
> to the same variable? A naive check for that would be O(N^2) in the
> number of entries in the conf file, but perhaps that's still cheap enough
> in practice. This would mean for example that
>
> shared_buffers = 'oops'
> shared_buffers = '128MB'
>
> would not draw an error, which doesn't bother me but might bother
> somebody.

Wouldn't bother me overly much. But it doesn't seem too hard to avoid
it. Simply split the current ProcessConfigFile() into one more phase.
Currently we seem to be parsing the config file, then iterate over the
list returned from that to set options. If we'd instead have one pass
over the items storing the new value in a new config_generic variable,
after checking, and then a second pass over all gucs setting those that
have changed we should end up at the same complexity since it could be
merged with the reset pass.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services