Re: Incorrectly reporting config errors - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Incorrectly reporting config errors
Date
Msg-id 20140122172302.GC30218@alap3.anarazel.de
Whole thread Raw
In response to Re: Incorrectly reporting config errors  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-01-22 12:10:30 -0500, Tom Lane wrote:
> Kevin Grittner <kgrittn@ymail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dynamic shared memory and locks
Next
From: Heikki Linnakangas
Date:
Subject: Re: GIN improvements part 1: additional information