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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Merging postgresql.conf and postgresql.auto.conf
Дата
Msg-id CAA4eK1LSLO=Ai3XNrb2B3iQCu5OPbzonaHvDYdW2498_=4tS5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Merging postgresql.conf and postgresql.auto.conf  (David Johnston <david.g.johnston@gmail.com>)
Ответы Re: Merging postgresql.conf and postgresql.auto.conf  (David Johnston <david.g.johnston@gmail.com>)
Re: Merging postgresql.conf and postgresql.auto.conf  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sat, Jan 17, 2015 at 10:41 AM, David Johnston <david.g.johnston@gmail.com> wrote:
> On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <david.g.johnston@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)?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: David Johnston
Дата:
Сообщение: Re: Merging postgresql.conf and postgresql.auto.conf
Следующее
От: David Johnston
Дата:
Сообщение: Re: Merging postgresql.conf and postgresql.auto.conf