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

From Amit Kapila
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
Msg-id CAA4eK1+89LH4g02=esW6yCF0xMesTFUsPd1+EH9DeheobdD__Q@mail.gmail.com
Whole thread Raw
In response to Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Stephen Frost <sfrost@snowman.net>)
Responses Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Aug 20, 2013 at 6:55 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Amit Kapila (amit.kapila16@gmail.com) wrote:
>> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > I'm not particularly set on this..  Why not create the file initially?
>>    If by default this feature needs to be disabled, then it is not
>> must to have at initdb time.
>
> I don't see how the two are related.  You could never use two-phase
> commit (could even disable it), yet we still create things in the data
> directory to support it.  Having a file in the data directory which
> isn't used by default isn't that big a deal, imv.
  Yes, it can be done, what I wanted to say it is not a "must",
rather a good to have thing.

>>    Also you mentioned below line upthread which I understood as you
>> don't like idea of creating empty file at initdb
>>    time:
>>    "If it's enabled by default, then we need to ship an 'auto' file which is
>>     empty by default...  I don't particularly like that"
>
> What I didn't like was having an empty file be accepted as 'valid', but
> you need to have some kind of bootstrap mechanism.  Telling users "run
> this command and then ignore the warning" is certainly bad.  A better
> option might be to have a *non-empty* auto.conf be generated, where all
> it has in it is some kind of identifier, perhaps even just
> "enable_alter_system = on" which we could then key off of to see if
> ALTER SYSTEM has been set up to be allowed or not.

Wouldn't it be complicated to handle this way rather then by having
include directive.
If include directive is enabled then the autofile will be read else no
need to read it.

If we want to have separate identifier to judge ALTER SYSTEM is enable
or not, then it is better to go with a new GUC.

>>  I think if we choose to use include directive as a way to
>> enable/disable this feature, it will not be good to allow change of
>> this parameter with Alter System.
>
> I agree, but then we need to add it to the list of things ALTER SYSTEM
> can't modify (if the include is implemented as a GUC, that is; I've not
> looked).
  I have checked and it seems to be just parse time thing.

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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL PERFORM with CTE
Next
From: Stephen Frost
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])