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

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>
Cc: "'Josh Berkus'" <josh(at)agliodbs(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-07-29 11:47:57
Message-ID: 008101ce8c51$78e890b0$6ab9b210$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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 value and user
set it to default, before this modification ,it
will write empty file.

With Regards,
Amit Kapila.

Attachment Content-Type Size
alter_system_v7.patch application/octet-stream 38.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-07-29 12:02:38 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Andres Freund 2013-07-29 11:36:01 Re: Bison 3.0 updates