Re: User Level Lock question

I know it does not sound like something that would need to be done, but here
is why I am looking at doing this...

I am trying to replace a low level ISAM database with PostgreSQL. The low
level ISAM db allows locking a record during a read to allow Exclusive
access to the record for that process. If someone tries to do a READ
operation on that record, it is skipped. I have to duplicate this
functionality. The application also allows locking multiple records and then
unlocking individual records or unlocking all of them at once. This cannot
be done easily with PostgreSQL unless I add a "status" field to the records
and manage them. This can be done, but User Level Locks seem like a much
better solution as they provide faster locking, no writes to the database,
when the backend quits all locks are released automatically, and I could
lock multiple records and then clear them as needed. They also exist outside
of transactions!

So my idea was to use User Level Locks on records and then include a test on
the lock status in my SELECT statements to filter out any records that have
a User Level Lock on it. I don't need to set it during the query, just test
if there is a lock to remove them from the query. When I need to do a true
lock during the SELECT, I can do it with the supplied routines.

Does this make any more sense now or have I made it that much more
confusing?

Lance

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Friday, March 15, 2002 9:11 AM
Subject: Re: [HACKERS] User Level Lock question

> "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com> writes:
> > Is there an easy way to test the lock on a user level lock without
actually
> > issuing the lock?
>
> Why would you ever want to do such a thing? If you "test" the lock but
> don't actually acquire it, someone else might acquire the lock half a
> microsecond after you look at it --- and then what does your test result
> mean? It's certainly unsafe to take any action based on assuming that
> the lock is free.
>
> I suspect what you really want is a conditional acquire, which you can
> get (in recent versions) using the dontWait parameter to LockAcquire.
>
> regards, tom lane