Re: postgresql.auto.conf and reload

On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
wrote:
> > On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Fujii Masao <masao(dot)fujii(at)gmail(dot)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.
>
> Applied the slightly-modified version!

Thanks. There is a commitfest entry [1] for this patch, do you
want some thing more to be addressed or shall we mark that as
committed.

[1]
https://commitfest.postgresql.org/action/patch_view?id=1500

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