Re: postgresql.auto.conf and reload

On Thu, Aug 7, 2014 at 12:28 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> 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

Yeah, let's mark this as committed because your patch has been committed and
the originally-reported problem has been fixed. We are now discussing another
patch, but I will add that as new CF entry.

Regards,

--
Fujii Masao