On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Sat, Jan 17, 2015 at 10:41 AM, David Johnston < > david.g.johns...@gmail.com> wrote: > > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > >> > >> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < > david.g.johns...@gmail.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. David J.
