Re: Incorrectly reporting config errors

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Incorrectly reporting config errors
Дата
Msg-id 20140122172302.GC30218@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Incorrectly reporting config errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: dynamic shared memory and locks
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: GIN improvements part 1: additional information