On Mon, 2007-09-24 at 21:26 -0500, Jaime Casanova wrote:
> On 9/24/07, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
> > > On 6/19/07, Simon Riggs <simon@2ndquadrant.com> wrote:
> > > >
> > > > related TODO items:
> > > > - add a WAIT n clause in same SQL locations as NOWAIT
> > > > - add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)
> > > >
> > > > to provide better control over lock waits.
> > > >
> > >
> > > are these actual TODO items? i can't find them on the TODO list and i
> > > don't remember any discussion nor patch about this
> >
> > They are my proposals for TODO items to assist with application
> > development.
> >
>
> while i'm not at all comfortable with the idea of a GUC for this, the
> WAIT clause seems to be useful.
> just out of curiosity, why the NOWAIT patch wasn't do it that way in
> first place, i mean like a WAIT clause and when receiving NOWAIT
> transform it in WAIT 0?
> maybe dicussion?
NOWAIT is used by Oracle.
DB2 supports a lock wait timeout.
What I didn't know before googling this was that SQLServer uses NOWAIT
also. SQLServer also implement WAIT [n seconds] *and* a parameter called
"lock wait period", which is pretty spooky.
Another reason to implement this is to help avoid global deadlocks in
distributed transactions (e.g. two phase).
SQLServer and DB2 have more need of this than PostgreSQL, but we do
still need it.
> there's concensus in adding a WAIT clause?
Just do it, but take careful note of any comments against things.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
