Re: Proposal: knowing detail of config files via SQL

Поиск
Список
Период
Сортировка
От Sawada Masahiko
Тема Re: Proposal: knowing detail of config files via SQL
Дата
Msg-id CAD21AoCpvJrW4dwusd2XO1e1PEX1RNPv1PwZjDY0zd7QRHhyQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: knowing detail of config files via SQL  (David Fetter <david@fetter.org>)
Ответы Re: Proposal: knowing detail of config files via SQL  (Mike Blackwell <mike.blackwell@rrd.com>)
Re: Proposal: knowing detail of config files via SQL  (David Fetter <david@fetter.org>)
Список pgsql-hackers
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

Regards,

-------
Sawada Masahiko



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Buildfarm broken for 9.3 and up
Следующее
От: Mike Blackwell
Дата:
Сообщение: Re: Proposal: knowing detail of config files via SQL