Re: Proposal: knowing detail of config files via SQL - Mailing list pgsql-hackers
From | David Fetter |
---|---|
Subject | Re: Proposal: knowing detail of config files via SQL |
Date | |
Msg-id | 20150130190552.GA14031@fetter.org Whole thread Raw |
In response to | Re: Proposal: knowing detail of config files via SQL (Sawada Masahiko <sawada.mshk@gmail.com>) |
Responses |
Re: Proposal: knowing detail of config files via SQL
|
List | pgsql-hackers |
On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote: > On Sat, Jan 31, 2015 at 12:24 AM, David Fetter <david@fetter.org> wrote: > > On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote: > >> On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas <robertmhaas@gmail.com> wrote: > >> > On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> >> David Johnston <david.g.johnston@gmail.com> writes: > >> >>> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> >>>> Is that a requirement, and if so why? Because this proposal doesn't > >> >>>> guarantee any such knowledge AFAICS. > >> >> > >> >>> The proposal provides for SQL access to all possible sources of variable > >> >>> value setting and, ideally, a means of ordering them in priority order, so > >> >>> that a search for TimeZone would return two records, one for > >> >>> postgresql.auto.conf and one for postgresql.conf - which are numbered 1 and > >> >>> 2 respectively - so that in looking at that result if the > >> >>> postgresql.auto.conf entry were to be removed the user would know that what > >> >>> the value is in postgresql.conf that would become active. Furthermore, if > >> >>> postgresql.conf has a setting AND there is a mapping in an #included file > >> >>> that information would be accessible via SQL as well. > >> >> > >> >> I know what the proposal is. What I am questioning is the use-case that > >> >> justifies having us build and support all this extra mechanism. How often > >> >> does anyone need to know what the "next down" variable value would be? > >> > > >> > I believe I've run into situations where this would be useful. I > >> > wouldn't be willing to put in the effort to do this myself, but I > >> > wouldn't be prepared to vote against a high-quality patch that someone > >> > else felt motivated to write. > >> > > >> > >> Attached patch adds new view pg_file_settings (WIP version). > >> This view behaves like followings, > >> [postgres][5432](1)=# select * from pg_file_settings ; > >> name | setting | > >> sourcefile > >> ----------------------------+--------------------+-------------------------------------------------------- > >> max_connections | 100 | > >> /home/masahiko/pgsql/master/3data/postgresql.conf > >> shared_buffers | 128MB | > >> /home/masahiko/pgsql/master/3data/postgresql.conf > > > > This looks great! > > > > Is there a reason not to have the sourcefile as a column in > > pg_settings? > > > > pg_file_settings view also has source file column same as pg_settings. > It might was hard to confirm that column in previous mail. > I put example of pg_file_settings again as follows. > > [postgres][5432](1)=# select * from pg_file_settings where name = 'work_mem'; > -[ RECORD 1 ]------------------------------------------------------ > name | work_mem > setting | 128MB > sourcefile | /home/masahiko/pgsql/master/3data/hoge.conf > -[ RECORD 2 ]------------------------------------------------------ > name | work_mem > setting | 64MB > sourcefile | /home/masahiko/pgsql/master/3data/postgresql.auto.conf Masuhiko-san, I apologize for not communicating clearly. My alternative proposal is to add a NULL-able sourcefile column to pg_settings. This is as an alternative to creating a new pg_file_settings view. Why might the contents of pg_settings be different from what would be in pg_file_settings, apart from the existence of this column? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
pgsql-hackers by date: