| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Subject: | Re: advisory locks and permissions |
| Date: | 2006-09-21 15:01:59 |
| Message-ID: | 20060921150159.GF24675@kenobi.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> An admin who is concerned about this can revoke public access on the
> functions for himself ... but should that be the default out-of-the-box
> configuration? I feel more comfortable with saying "you have to turn
> on this potentially-dangerous feature" than with saying you have to turn
> it off.
I agree with having it turned off by default, at least in 8.2. Once
it's out there and in use we can review that decision for 8.3 and
possibly implement appropriate safeguards based on the usage.
> Another reason for restricting access to the advisory-lock functions
> is that an uninformed application might take the wrong locks, and
> bollix up your intended usage accidentally.
This begs for a mechanism to define who can take what locks, etc..
Which seems to be an 8.3 issue.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-09-21 15:24:53 | Re: Release Notes: Major Changes in 8.2 |
| Previous Message | Peter Eisentraut | 2006-09-21 14:53:03 | Re: 'configure --disable-shared' and 'make check' |