Re: Merging postgresql.conf and postgresql.auto.conf

On Sat, Jan 17, 2015 at 2:24 PM, David Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
>>
>> On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
>> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
>> > wrote:
>> >>
>> >> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
>> >> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> >> > > You're right.
>> >> > > pg_setting and SHOW command use value in current session rather
>> >> > > than
>> >> > > config file.
>> >> > > It might break these common infrastructure.
>> >> >
>> >> > Two changes solve this problem in what seems to be a clean way.
>> >> > 1) Upon each parsing of postgresql.conf we store all assigned
>> >> > variables
>> >> > somewhere
>> >> > 2) We display these assignments in a new pg_settings column named
>> >> > "system_reset_val"
>> >> >
>> >> > I would also extend this to include:
>> >> > a) upon each parsing of postgresql.auto.conf we store all assigned
>> >> > variables
>> >> > somewhere (maybe the same place as postgresql.conf and simply label
>> >> > the file
>> >> > source)
>> >>
>> >> Do we need to perform this parsing whenever user queries pg_settings?
>> >> I think it might lead to extra cycles of reading file when user won't
>> >> even
>> >> need it and as the code is shared with SHOW commands that could be
>> >> slightly complicated.
>> >>
>> >
>> > There would be no parsing upon reading of pg_settings, only lookups.
>> > The existing parsing would simply have its values saved to the catalogs that
>> > will be involved in the underlying pg_setting view query.
>> >
>> So are you telling that whenever we read, save the settings
>> to some catalog (probably a new one)?
>>
>> Will that completely address the problem specified in this thread,
>> as those values could probably be old (when last time server is
>> started or at last SIGHUP time values)?
>>
>
> Cache invalidation is a hard problem to solve :)
>
> I am reasonably content with showing the user who has just updated their
> postgresql.conf file and boots/SIGHUPs the server to find that said value
> hasn't taken effect that their value is indeed sitting in postgresql.conf
> but that other parts of the system are preempting it from being the active
> value.
>

I think it is enough to parse and store them only when server is
started and received SIGHUP.
(Probably we should add new function to read(not load) config files to
updated these new values in pg_settings like pg_read_conf())

In idea David suggested, we would not able to know name of included
file in postgresql.conf, and duplicated values in postgresql.conf.
Are they unnecessary?

Regards,

-------
Sawada Masahiko