Re: ALTER SYSTEM vs symlink

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER SYSTEM vs symlink
Date: 2015-11-03 03:40:25
Message-ID: 6270.1446522025@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajeev rastogi 2015-11-03 05:37:41 Re: Dangling Client Backend Process
Previous Message Amit Kapila 2015-11-03 03:33:49 Re: Freeze avoidance of very large table.