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
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.
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,
integration, and testing schemas in the same database. This makes it
trivial to move testing data to development, for example.
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.
-M
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
