From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(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-28 18:03:06 |
Message-ID: | CAHGQGwG1q2Lo4BcpzGMJ6gQqVDKKLPUN3fxSmwfsEwRLEvuXPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
>> wrote:
>> > Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
>> > config params, retain only which comes later during parsing.
>> > I think it might have been bit simpler to fix, if we try to fix after
>> > parsing
>> > is complete, but I think for that we might need to replicate the logic
>> > at multiple places.
>>
>> ISTM that the patch works fine. Only concern is that the logic needs
>> O(n^2) comparison, which may cause performance problem. But
>> "n" in O(n^2) is the number of uncommented parameters and I don't
>> think it's so big, ISTM I can live with the logic...
>
> Thanks for reviewing the patch. I also think that having O(n^2)
> comparisons should not be a problem in this logic as it will be processed
> only during load/parse of config file which we don't do in performance
> sensitive path.
Yep.
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.
Can we live with this issue?
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-07-28 18:33:58 | Re: postgresql.auto.conf and reload |
Previous Message | Andres Freund | 2014-07-28 17:50:51 | Re: pg_background (and more parallelism infrastructure patches) |