Re: [HACKERS] ALTER SYSTEM vs symlink

On Tue, Nov 3, 2015 at 6:08 AM, Robert Haas wrote: > On Mon, Nov 2, 2015 at 3:41 PM, Stephen Frost wrote: >>> Two different methods of restricting ALTER SYSTEM have already been >>> discussed on this thread: one using file permissions, and the other >>>

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 10:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila wrote: >>> I think that is the sensible way to deal with this and any other such >>> parameters. We already

Re: [HACKERS] ALTER SYSTEM vs symlink

Andrew Dunstan writes: > I don't know if this was discussed at the time ALTER SYSTEM was > implemented, but I have just discovered that if postgresql.auto.conf is > a symlink to a file elsewhere, ALTER SYSTEM will happily break that link > and write its own local copy.

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 09:36 AM, Tom Lane wrote: Andrew Dunstan writes: I don't know if this was discussed at the time ALTER SYSTEM was implemented, but I have just discovered that if postgresql.auto.conf is a symlink to a file elsewhere, ALTER SYSTEM will happily break that link

Re: [HACKERS] ALTER SYSTEM vs symlink

On 2015-11-02 09:43:02 -0500, Stephen Frost wrote: > What this request strikes me as asking for is the same as what I asked > for when this feature was originally going in- there should be a way to > disable it. You can just revoke permissions on the file if necessary. Results in the expected

Re: [HACKERS] ALTER SYSTEM vs symlink

* Andrew Dunstan (and...@dunslane.net) wrote: > On 11/02/2015 09:36 AM, Tom Lane wrote: > >Andrew Dunstan writes: > >>I don't know if this was discussed at the time ALTER SYSTEM was > >>implemented, but I have just discovered that if postgresql.auto.conf is > >>a symlink to a

Re: [HACKERS] ALTER SYSTEM vs symlink

* Andres Freund (and...@anarazel.de) wrote: > On 2015-11-02 09:43:02 -0500, Stephen Frost wrote: > > What this request strikes me as asking for is the same as what I asked > > for when this feature was originally going in- there should be a way to > > disable it. > > You can just revoke

Re: [HACKERS] ALTER SYSTEM vs symlink

Stephen Frost writes: > * Andres Freund (and...@anarazel.de) wrote: >> You can just revoke permissions on the file if necessary. Results in the >> expected >> ERROR: XX000: could not open file "../postgresql.auto.conf": Permission >> denied > Yes, I know, but that's a

Re: [HACKERS] ALTER SYSTEM vs symlink

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > I don't know if this was discussed at the time ALTER SYSTEM was > > implemented, but I have just discovered that if postgresql.auto.conf is > > a symlink to a file elsewhere, ALTER SYSTEM will happily break

Re: [HACKERS] ALTER SYSTEM vs symlink

Robert Haas writes: > On Mon, Nov 2, 2015 at 10:14 AM, Tom Lane wrote: >> While I won't stand in the way if someone is dead set on providing a >> disable switch for ALTER SYSTEM, I fail to see the point of one. > I have not seen much evidence that the

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 09:24 AM, Stephen Frost wrote: > I certainly look forward to having more fine grained control, to the > point where I'd like to be able to run a system reasonably without an > active superuser login. Having superusers logging into production > running databases is extremely

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 11:39 AM, Stephen Frost wrote: > This is all very environment specific. Changes to postgresql.conf, in > many environments, go through a serious of tests before being deployed > by a CM system. How do we accomplish the same kind of tests before >

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 10:14 AM, Tom Lane wrote: > Stephen Frost writes: >> * Andres Freund (and...@anarazel.de) wrote: >>> You can just revoke permissions on the file if necessary. Results in the >>> expected >>> ERROR: XX000: could not open file

Re: [HACKERS] ALTER SYSTEM vs symlink

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Andres Freund (and...@anarazel.de) wrote: > >> You can just revoke permissions on the file if necessary. Results in the > >> expected > >> ERROR: XX000: could not open file "../postgresql.auto.conf":

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 08:33 AM, Stephen Frost wrote: > A deeper hook in the ALTER SYSTEM might be another approach, or one > in the GUC system to allow external libraries to control what various > GUCs can be set to (either via ALTER SYSTEM or through regular SET > calls). I have run into multiple

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 06:36 AM, Tom Lane wrote: > Andrew Dunstan writes: >> I don't know if this was discussed at the time ALTER SYSTEM was >> implemented, but I have just discovered that if postgresql.auto.conf is >> a symlink to a file elsewhere, ALTER SYSTEM will happily break

Re: [HACKERS] ALTER SYSTEM vs symlink

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Nov 2, 2015 at 11:39 AM, Stephen Frost wrote: > > This is all very environment specific. Changes to postgresql.conf, in > > many environments, go through a serious of tests before being deployed > > by a CM system. How

Re: [HACKERS] ALTER SYSTEM vs symlink

Robert, Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > I would be willing to wager that a lot more people will hose their > > systems by avoiding ALTER SYSTEM than will do so by using it. > > Well, mumble --- the subtext I thought I was hearing from

Re: [HACKERS] ALTER SYSTEM vs symlink

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Well, mumble --- the subtext I thought I was hearing from Stephen was > >> that he'd not give his DBAs write access on postgresql.conf either. > >> But yes, pushing

Re: [HACKERS] ALTER SYSTEM vs symlink

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> How is it that we don't need rolcatupdate but we do need a way to shut >> off ALTER SYSTEM? Doesn't compute, IMO. > I'd like the ability to control all of the above, ultimately. I don't > believe that we

Re: [HACKERS] ALTER SYSTEM vs symlink

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Well, mumble --- the subtext I thought I was hearing from Stephen was >> that he'd not give his DBAs write access on postgresql.conf either. >> But yes, pushing people away from ALTER SYSTEM and towards manual

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 3:41 PM, Stephen Frost wrote: >> Two different methods of restricting ALTER SYSTEM have already been >> discussed on this thread: one using file permissions, and the other >> using ProcessUtility_hook. I personally think that's good enough. > > The

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila 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

Re: [HACKERS] ALTER SYSTEM vs symlink

On Mon, Nov 2, 2015 at 10:17 PM, Tom Lane wrote: > > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> How is it that we don't need rolcatupdate but we do need a way to shut > >> off ALTER SYSTEM? Doesn't compute, IMO. > > > I'd like

Re: [HACKERS] ALTER SYSTEM vs symlink

Robert Haas writes: > On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila 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