Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Дата
Msg-id 008101ce8c51$78e890b0$6ab9b210$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Amit kapila <amit.kapila@huawei.com>)
Ответы Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Cédric Villemain <cedric@2ndquadrant.com>)
Список pgsql-hackers
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> >> The main contention point I see is where conf.d lives;
> >> the two options are in $PGDATA or together with postgresql.conf.
> Tom
> >> and Robert, above, say it should be in $PGDATA; but this goes
> against
> >> Debian packaging and the Linux FHS (or whatever that thing is
> called).
> 
> > Ordinarily, if postgresql.conf is not in $PGDATA, it will be
> somewhere
> > that the postmaster does not (and should not) have write permissions
> > for.  I have no objection to inventiny a conf.d subdirectory, I just
> say
> > that it must be under $PGDATA.  The argument that this is against FHS
> > is utter nonsense, because anything we write there is not static
> > configuration, it's just data.
> 
> > Come to think of it, maybe part of the reason we're having such a
> hard
> > time getting to consensus is that people are conflating the "snippet"
> > part with the "writable" part?  I mean, if you are thinking you want
> > system-management tools to be able to drop in configuration fragments
> as
> > separate files, there's a case to be made for a conf.d subdirectory
> that
> > lives somewhere that the postmaster can't necessarily write.  We just
> > mustn't confuse that with support for ALTER SYSTEM SET.  I strongly
> > believe that ALTER SYSTEM SET must not be designed to write anywhere
> > outside $PGDATA.
> 
> I think if we can design conf.d separately for config files of
> management tools, then
> it is better to have postgresql.auto.conf to be in $PGDATA rather than
> in
> $PGDATA/conf.d
> 
> Kindly let me know if you feel otherwise, else I will update and send
> patch
> tomorrow.

Modified patch to have postgresql.auto.conf in $PGDATA. Changes are as
below:

1. initdb to create auto file in $PGDATA
2. ProcessConfigFile to open auto file from data directory, special case
handling for initdb
3. AlterSystemSetConfigFile function to consider data directory as reference
for operating on auto file
4. modified comments in code and docs to remove usage of config directory
5. modified function write_auto_conf_file() such that even if there is no
configuration item to write, it should write header message.  This is to handle case when there is only one parameter
valueand user
 
set it to default, before this modification ,it   will write empty file.

With Regards,
Amit Kapila.

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

Предыдущее
От: Szymon Guz
Дата:
Сообщение: Re: ToDo: possible more rights to database owners
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bison 3.0 updates