Re: postgresql.auto.conf and reload

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: postgresql.auto.conf and reload
Дата
Msg-id CAA4eK1L75O4rS_Ldnz4TCbCNByQv+URSHSi+BXPuuBpR3fsG2A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgresql.auto.conf and reload  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: postgresql.auto.conf and reload  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> There is other side effect on this patch. With the patch, when reloading
> the configurartion file, the server cannot warm an invalid setting value
> if it's not the last setting of the parameter. This may cause problematic
> situation as follows.
>
> 1. ALTER SYSTEM SET work_mem TO '1024kB';
> 2. Reload the configuration file ---> success
> 3. Then, a user accidentally adds "work_mem = '2048KB'" into postgresql.conf
>      The setting value '2048KB' is invalid, and the unit should be
> 'kB' instead of 'KB'.
> 4. Reload the configuration file ---> success
>      The invalid setting is ignored because the setting of work_mem in
>      postgresql.auto.conf is preferred. So a user cannot notice that
> postgresql.conf
>      has an invalid setting.
> 5. Failover on shared-disk HA configuration happens, then PostgreSQL fails to
>     start up because of such an invalid setting. When PostgreSQL
> starts up, the last
>     setting is preferred. But all the settings are checked.

The reason is that during startup DataDir is not set by the time server
processes config file due to which we process .auto.conf file in second
pass.  I think ideally it should ignore the invalid setting in such a case
as it does during reload, however currently there is no good way to
process .auto.conf  incase DataDir is not set, so we handle it separately
in second pass.  

> Can we live with this issue?

If you are worried about the Reload success case, it will anyway fail later
on if user actually wants to set it via postgresql.conf because in such a
case user has to remove the setting  set by Alter System using
Alter System <param_name> To Default.  Incase he doesn't have any
such intention, then I think ignoring such invalid params is not a concerning
issue.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Minmax indexes
Следующее
От: "MauMau"
Дата:
Сообщение: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations