On Thu, Aug 7, 2014 at 12:28 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao <masao.fu...@gmail.com> >> wrote: >> > On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Fujii Masao <masao.fu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
