Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I guess it is a compatibility change, but weighing compatibility against > clarity, I am leaning toward clarity. I assume it is this line that > would be changed: > _("user lock [%u,%u,%u,%u]"), You assume wrong ... that has nothing to do with wha

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Bruce Momjian
Merlin Moncure wrote: > On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > I don't see the column rename as an > > > API change issue. > > > > How can you possibly claim it's not an API change? > > > > i dunno, i agree with bruce here. we are just

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't see the column rename as an > API change issue. How can you possibly claim it's not an API change? i dunno, i agree with bruce here. we are just changing the output of pg_locks a bit reflectin

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't see the column rename as an > API change issue. How can you possibly claim it's not an API change? If you're insistent on this, my recommendation would be to add a new LOCKTAG value for advisory locks instead of re-using LOCKTAG_USERLOCK. This w

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote: > Except you can put tables (and pretty much all your other objects) > in a > schema, one that's presumably named after your application. That > greatly > removes the odds of conficts. Indeed. In our development environment, we store development, int

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> (b) we put up that pgfoundry module so that there would be a backward > >> compatible solution. Won't be very backward compatible if the locks > >> look different in pg_locks. > > > But is anyone going to know wh

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> (b) we put up that pgfoundry module so that there would be a backward >> compatible solution. Won't be very backward compatible if the locks >> look different in pg_locks. > But is anyone going to know what userlocks is in 1-2 years?

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
AgentM <[EMAIL PROTECTED]> writes: > If I want to use these locks, it seems I will have to hard-code some > offset into each app or hash the schema name and use that as an > offset :( In any case, I can't imagine the "wtf?" nightmares an > accidental collision would induce. That depends enti

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I'm disinclined to change that, because it would probably break existing > >> client-side code for little gain. > > > I think clarity suggests we should make the heading match the feature, > > i.e call it "advisor

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Stephen Frost
* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > * Tom Lane ([EMAIL PROTECTED]) 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 f

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Ahh, ok, I didn't realize that the total lock space was larger than > what's being exposed today. That means we can easily add that stuff in > the future and not break anything, which is all I was looking for. Yeah --- in particular, we can always add m

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I'm disinclined to change that, because it would probably break existing >> client-side code for little gain. > I think clarity suggests we should make the heading match the feature, > i.e call it "advisory" rather than "userlock". W

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Bruce Momjian
Tom Lane wrote: > "Merlin Moncure" <[EMAIL PROTECTED]> writes: > > advisory locks still show up as 'userlock' in the pg_locks view. does > > this matter? > > I'm disinclined to change that, because it would probably break existing > client-side code for little gain. I think clarity suggests we s

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread AgentM
On Sep 22, 2006, at 14:11 , Jim C. Nasby wrote: On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote: On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote: the whole point about advisory locks is that the provided lock

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Merlin Moncure" <[EMAIL PROTECTED]> writes: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: >> This is why I suggested we set aside some range of numbers that should >> not be used. Doing so would allow adding a better-managed >> numbering/na

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Jim C. Nasby
On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > >I'm not asking for a defined solution to how to support multiple > >different users of locks within the same database. I just want us to set > >aside (as in, recommend they not b

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
"Merlin Moncure" <[EMAIL PROTECTED]> writes: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: >> This is why I suggested we set aside some range of numbers that should >> not be used. Doing so would allow adding a better-managed >> numbering/naming scheme in the future. > the whole point abou

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: I'm not asking for a defined solution to how to support multiple different users of locks within the same database. I just want us to set aside (as in, recommend they not be used) some set of numbers so that in the future we could recommend a me

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Jim C. Nasby
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > >On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote: > >> the whole point about advisory locks is that the provided lock space > >> is unmanaged. for example, in the I

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote: > the whole point about advisory locks is that the provided lock space > is unmanaged. for example, in the ISAM system I wrote which hooked > into the acucobol virtual file system i

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Jim C. Nasby
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > >This is why I suggested we set aside some range of numbers that should > >not be used. Doing so would allow adding a better-managed > >numbering/naming scheme in the future. > >

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread AgentM
On Sep 22, 2006, at 12:46 , Merlin Moncure wrote: On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote: I would be more worried about accidental collisions between applications. The lock ranges will now need to be in their respective i dont think this argument has merit because the lock is scoped to

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: This is why I suggested we set aside some range of numbers that should not be used. Doing so would allow adding a better-managed numbering/naming scheme in the future. the whole point about advisory locks is that the provided lock space is unm

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote: I would be more worried about accidental collisions between applications. The lock ranges will now need to be in their respective i dont think this argument has merit because the lock is scoped to the current database. this would only be a problem

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Jim C. Nasby
On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote: > > On Sep 22, 2006, at 11:26 , Merlin Moncure wrote: > > >On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: > >>Stephen Frost <[EMAIL PROTECTED]> writes: > >>> * Tom Lane ([EMAIL PROTECTED]) wrote: > An admin who is concerned about this

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread AgentM
On Sep 22, 2006, at 11:26 , Merlin Moncure wrote: On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) wrote: >> An admin who is concerned about this can revoke public access on the >> functions for himself ... but should

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Joshua D. Drake
there are plenty of other potentially nasty things (like generate_series and the ! operator). why are advisory_locks handled specially? the way it stands right now is a user with command access can DoS a server after five minutes of research on the web. You don't even have to do any researc

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
"Merlin Moncure" <[EMAIL PROTECTED]> writes: > advisory locks still show up as 'userlock' in the pg_locks view. does > this matter? I'm disinclined to change that, because it would probably break existing client-side code for little gain. regards, tom lane --

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Merlin Moncure
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) 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

Re: [HACKERS] advisory locks and permissions

2006-09-22 Thread Tom Lane
Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) 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 tu

Re: [HACKERS] advisory locks and permissions

2006-09-21 Thread Kevin Brown
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Doesn't creating many temp tables in a transaction do the same thing? > > True, but it's a tad harder/less likely that you'd accidentally cause > a problem that way. Then why not use a GUC (that only an administrator can set) to cont

Re: [HACKERS] advisory locks and permissions

2006-09-21 Thread Stephen Frost
* Tom Lane ([EMAIL PROTECTED]) 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" tha

Re: [HACKERS] advisory locks and permissions

2006-09-21 Thread Dimitri Fontaine
Le jeudi 21 septembre 2006 01:52, Tom Lane a écrit : > Or we could try to do something about limiting the number of such locks > that can be granted, but that seems nontrivial to tackle at such a late > stage of the devel cycle. > > Thoughts? What about reserving some amount of shared_buffers out

Re: [HACKERS] advisory locks and permissions

2006-09-21 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Doesn't creating many temp tables in a transaction do the same thing? True, but it's a tad harder/less likely that you'd accidentally cause a problem that way. I'm not sure if I'm crying wolf or whether there's a serious issue. Certainly, if you have SQ

Re: [HACKERS] advisory locks and permissions

2006-09-20 Thread Jeremy Drake
On Wed, 20 Sep 2006, Bruce Momjian wrote: > > Doesn't creating many temp tables in a transaction do the same thing? > > --- Like this? jeremyd=# CREATE OR REPLACE FUNCTION testy(n integer) returns integer as $$ BEGIN EXECUT

Re: [HACKERS] advisory locks and permissions

2006-09-20 Thread Bruce Momjian
Doesn't creating many temp tables in a transaction do the same thing? --- Josh Berkus wrote: > All, > > > I vote for locking down to superuser access (lets be frank here: I > > would estimate 90%+ database installatons run

Re: [HACKERS] advisory locks and permissions

2006-09-20 Thread Josh Berkus
All, > I vote for locking down to superuser access (lets be frank here: I > would estimate 90%+ database installatons run with the application as > root) so we are not losing much. Not in my experience. Note that making them superuser-only pretty much puts them out of the hands of hosted appli

Re: [HACKERS] advisory locks and permissions

2006-09-20 Thread Merlin Moncure
On 9/21/06, Tom Lane <[EMAIL PROTECTED]> wrote: One good thing about advisory locks having been in contrib was that they didn't affect anyone who didn't actually install the module. Now that we've put those functions in core, I wonder whether we don't need to face up to the possibility of malici

Re: [HACKERS] advisory locks and permissions

2006-09-20 Thread Jim C. Nasby
On Wed, Sep 20, 2006 at 07:52:33PM -0400, Tom Lane wrote: > face up to the possibility of malicious use. For instance, it's not > very hard to create a DoS situation by running the system out of shared > lock table space: Didn't you just say we don't try and protect against DoS? ;P > The brute f