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

On Tue, Aug 20, 2013 at 9:33 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Amit Kapila (amit(dot)kapila16(at)gmail(dot)com) wrote:
>> Do you mean to say, that when user uses ALTER SYSTEM and include is
>> disabled, then we can give ERROR in
>> ALTER SYSTEM, that to reflect the values, he need to enable it?
>> Actually in previous version of patch, there was WARNING on such a condition.
>> I agree that it can be detected and we issue Warning or Error, but
>> I think it will be an un-necessary inconvenience
>> for user. However if you still vote for disable by default, I will
>> modify the patch that way only.
>
> It hardly seems unnecessary.. Otherwise we accept a command that won't
> actually do anything, yes?

Okay, let us decide how things will be if we disable by default:
1. initdb won't create any empty auto file, rather the file will be
created first time user uses ALTER SYSTEM.
2. Alter system should issue warning, if it detects that feature is
disabled (for this we need to error detection code
during parsing of postgresql.conf as it was previously)
3. postgresql.conf will contain include directive in below form:
#include = 'postgresql.auto.conf'
Whenever user wants to use Alter System, he needs to enable it
after first time using ALTER SYSTEM.

One question here, if somebody just enables it without using ALTER
SYSTEM, should it throw any error on not finding auto file or just
ignore it?

> We usually notice or warn, at least, on such
> cases (see similar things around GRANT/REVOKE...).
>
>> The other part which needs suggestions is about un-safe parameters:
>> I think for first version of feature, we can decide on some minimum
>> list of parameters that will be considere un-safe and user will not be
>> allowed to modify them with ALTER SYSTEM.
>
> I do feel like it's easier to add things to the 'allowed' set later,
> should we see some good justification for it, than to disallow things
> already allowed.

Here the only consideration in my mind is about question of
usefulness of this feature and getting agreement on
long list of un-safe parameters.
As we are already proposing/planing to give FORCE option with which
user can change config parameters, the
question of usefulness can be answered with that, but how about other?

>> To start with we can consider below 4 parameters in that category and
>> later on keep adding more parameters:
>> data_directory, listen_addresses, port, shared_buffers.
>
> What about include directives?

Sorry, I didn't get which parameters you are referring by include directives?

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