Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> I think that is the sensible way to deal with this and any other such
>> parameters. We already have a way to disallow setting of individual
>> parameters (GUC_DISALLOW_IN_AUTO_FILE) via Alter System.
>> Currently we disallow to set data_directory via this mechanism and I think
>> we can do the same for other parameters if required. Do you think we
>> should do some investigation/analysis about un-safe parameters rather
>> then doing it in retail fashion?
> -1.
> This was discussed before, and I feel about it now the same way I felt
> about it then: disallowing all GUCs that could potentially cause the
> server not to start would make ALTER SYSTEM a whole lot less useful.
I definitely agree that unconditionally disallowing "unsafe" parameters
in ALTER SYSTEM would be counterproductive. data_directory is disallowed
there only because it's nonsensical: you can't even find the auto.conf
file until you've settled on the data_directory.
However, where I thought this discussion was going was to allow admins
to selectively disable particular parameters from being set that way.
Whether a particular installation finds locking down
shared_preload_libraries to be more useful than allowing it to be set
doesn't seem to me to be a one-size-fits-all question. So at least in
principle I'd be okay with a feature to control that. But maybe it's
sufficient to say "you can use sepgsql to restrict that". Not every
feature needs to be in core.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
