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.
merlin
