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 CAA4eK1LXbO9SGtW_wGmRWNxHWwogQr8Ua8QWyoWEM-gD4A2=WQ@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])  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
On Sat, Aug 24, 2013 at 6:08 PM, Martijn van Oosterhout
<kleptog@svana.org> wrote:
> On Fri, Aug 23, 2013 at 06:41:04PM +0530, Amit Kapila wrote:
>> > Not with this proposal...  If it's fixed then it makes no sense to make it
>> > look like it can be modified.
>>
>>    This proposal is to have a special include which user can only use
>> for enable/disable
>>    which means he can remove symbol '#' or add '#'.
>>    We cannot stop user from changing file name or add some different
>> location, but that can lead to problems.
>>    We can have a note on top of this include indicating it is only for
>> enable/disable.
>
> Note, my whole purpose for suggesting something like:
>
> include_auto_conf_file    postgresql.auto.conf
>
> is because I want the file location to be configurable. If I put in my
> configuration:
>
> include_auto_conf_file    /etc/postgresql/9.4/postgresql.auto.conf
>
> it better put the options there. And if I comment the line out ALTER
> SYSTEM should stop working.  If I put it at the beginning of the config
> then any other option in the file will override it (which we can detect
> and warn about).  If I put it at the end of the file, ALTER SYSTEM
> overrides any statically configured options.
>
> And I can imagine hosting providers putting the configuration for
> memory usage, shared library directories and other such options after,
> and options like cpu_cost, enable_merge_join, etc before.  That way
> they have fine grained control over which options the user can set and
> which not.
  Thanks for your suggestion.  Above usecase can be achieved even if the file is not configurable.

>>    I think if we add more meaning to it, like allow user to change it,
>> handling and defining of that will be bit complex.
>
> Letting the user configure the location seems like common curtesy. Note
> this line isn't in itself a GUC, so you can't configure it via ALTER
> SYSTEM.

In general yes it is better to give control to user for configuring
the location, but as this file will
be used for internal purpose and will be modified by system and not by
user, so it is better to
be in data directory. The similar thing was discussed previously on
this thread and it is suggested
to have this file in data directory.


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



pgsql-hackers by date:

Previous
From: Kanarupan Kularatnarajah
Date:
Subject: What is the algorithm used for counting the set bit (number of ones) of a bitmap/bitarray/betset in postgresql?
Next
From: Amit Kapila
Date:
Subject: Re: Behaviour of take over the synchronous replication