Re: postgresql.auto.conf and reload

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgresql.auto.conf and reload
Date: 2014-07-29 12:26:57
Message-ID: CAA4eK1L75O4rS_Ldnz4TCbCNByQv+URSHSi+BXPuuBpR3fsG2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2014-07-29 12:31:59 Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Previous Message Heikki Linnakangas 2014-07-29 11:33:20 Re: Minmax indexes