> Tom,
> 
> > I'd accept a mechanism to enforce a timeout at the lock level if you
> > could show me a convincing use-case for lock timeouts instead of
> > statement timeouts, but I don't believe there is one.  I think this
> > proposal is a solution in search of a problem.
> 
> Hmmm ... didn't we argue this out with NOWAIT?   What did we conclude
> then?
> I'm reluctant to go over old ground repeatedly.

The result of this debate was that there was some use for it.  NOWAIT is
now implemented for table locking but not for row locking.  

Personally I think there is some use for forcing transactions to abort
as soon as a lock situation is detected (although I probably wouldn't
use it).  For row level locking I would suggest to the original poster
to compare xmin/xmax (check the docs) to pre check the row level lock
condition.  This is inelegant but it mostly works.

FWIW, I think the treatment of locking in the docs could use some
improvement.  Especially wrt MVCC and pessimistic locking and the 'big
picture' issues going on there (especially why the former is better than
the latter).

Merlin

Tue, 29 Jun 2004 15:35:22 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: lock timeout patch
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> FWIW, I think the treatment of locking in the docs could use some
> improvement.  Especially wrt MVCC and pessimistic locking and the 'big
> picture' issues going on there (especially why the former is better than
> the latter).

Send a patch ...

			regards, tom lane

Tue, 29 Jun 2004 23:19:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: lock timeout patch 