Re: advisory locks and permissions

On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
> On 9/22/06, Jim C. Nasby <jim@nasby.net> 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 interface, I used  a global
> >> sequence for row level pessimistic locking but reserved the 48th bit
> >> for table level locks.  This system was extremely effective.  on the
> >> current system I'm working on I use them to lock sequence oid's plus a
> >> high bit indicator for what i am doing.  in short, advisory locks are
> >> application-defined in concept.
> >
> >Yes, but if you get two pieces of code written by different people using
> >them in the same database, you can get hosed. As PostgreSQL becomes more
> >popular and more people start developing software for it, this is more
> >likely to occur.
> 
> imo, that is no more or less likely than having two pieces of code
> store the same table in the same database.  I think what you are
> describing would only be a concern if the locks were shared across
> databases, however this is not the case.  the purpose of advisory
> locks is to be 'appplication-defined'.  how the application is written
> is not part of that concept.  we are simply granting the ability to
> create a mutex with a number for a name, that is all.

Ok, here's a real-world example. RRS (http://rrs.decibel.org) will make
use of userlocks if available. RRS by itself isn't very interesting at
all; you'd want to use it with something else. Because there's no
standard at all for carving up the numbers, I did the best I could by
using the OID of one of my functions, because at least back then there
was standard OID support. I'm not sure if that even made it into the
current version.

Using named locks is possibly overkill, but it would be good to at least
set aside some chunk of numbers so that it can be done.

Likewise I suggested setting aside OIDs above 10k (or whatever a normal
database starts numbering at) so that you could at least do per-schema
numbering.

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 means of picking lock numbers that will
avoid collisions.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)