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 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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
