Re: [HACKERS] please? - Mailing list pgsql-hackers

From Pablo Funes
Subject Re: [HACKERS] please?
Date
Msg-id 199906011609.MAA07086@mancha.cs.brandeis.edu
Whole thread Raw
In response to Re: [HACKERS] please?  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
> > 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.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] LIMITS
Next
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] which list?