Skip site navigation (1) Skip section navigation (2)

Re: lock timeout patch

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lock timeout patch
Date: 2004-06-29 19:35:22
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AE99@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-06-29 19:46:34
Subject: Default libpq service
Previous:From: Andrew DunstanDate: 2004-06-29 19:31:22
Subject: bounce messages

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group