Re: [HACKERS] please?

> > There is no way to do that in 6.4. I am not sure whether the MVCC
> > additions in 6.5 provide a way to do it or not (Vadim?).
>
> I want to have it in later versions.
>
> At the moment try to use contrib/userlock/
>

AHA! It looks like this solves my problem, at least for now,
until an official way to do nonblocking locs shows up on a
future release.
Here's what contrib/userlock/user_locks.doc says:

select some_fields, user_write_lock_oid(oid) from table where id='key';

Now if the returned user_write_lock_oid field is 1 you have acquired an
user lock on the oid of the selected tuple and can now do some long operation
on it, like let the data being edited by the user.

If it is 0 it means that the lock has been already acquired by some other
process and you should not use that item until the other has finished.

[...]

update table set some_fields where id='key';
select user_write_unlock_oid(oid) from table where id='key';

[...]

This could also be done by setting a flag in the record itself but in
this case you have the overhead of the updates to the records and there
could be some locks not released if the backend or the application crashes
before resetting the lock flag.

It could also be done with a begin/end block but in this case the entire
table would be locked by postgres and it is not acceptable to do this for
a long period because other transactions would block completely.