Re: postgresql.auto.conf and reload - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: postgresql.auto.conf and reload
Date
Msg-id CAA4eK1L75O4rS_Ldnz4TCbCNByQv+URSHSi+BXPuuBpR3fsG2A@mail.gmail.com
Whole thread Raw
In response to Re: postgresql.auto.conf and reload  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: postgresql.auto.conf and reload
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Minmax indexes
Next
From: "MauMau"
Date:
Subject: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations