Re: postgresql.auto.conf and reload

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: postgresql.auto.conf and reload
Дата
Msg-id CAHGQGwG3oS9p-j0Tb2Nyt5mxS5utBgpjBYqpJYTs5uvHehMWDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgresql.auto.conf and reload  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: postgresql.auto.conf and reload  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> The patch chooses the last settings for every parameters and ignores the
>> former settings. But I don't think that every parameters need to be processed
>> this way. That is, we can change the patch so that only PGC_POSTMASTER
>> parameters are processed that way. The invalid settings in the parameters
>> except PGC_POSTMASTER can be checked by pg_ctl reload as they are now.
>> Also this approach can reduce the number of comparison to choose the
>> last setting, i.e., "n" in O(n^2) is the number of uncommented *PGC_POSTMASTER*
>> parameters (not every parameters). Thought?
>
> I don't find that to be a particularly good idea.  In the first place,
> it introduces extra complication and a surprising difference in the
> behavior of different GUCs.  In the second place, I thought part of the
> point of this patch was to suppress log messages complaining about
> invalid values that then weren't actually used for anything.  That issue
> exists just as much for non-POSTMASTER variables.  (IOW, "value cannot
> be changed now" is not the only log message we're trying to suppress.)

Yep, sounds reasonable. This makes me think that we can suppress
such invalid message of the parameters which are actually not used
at not only conf file reload but also *postmaster startup*. That's another
story, though. Anyway, barring any objection, I will commit Amit's patch.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Use unique index for longer pathkeys.