Re: [HACKERS] 'Waiting on lock' - Mailing list pgsql-patches

From Jaime Casanova
Subject Re: [HACKERS] 'Waiting on lock'
Date
Msg-id c2d9e70e0709241926p29e063d9xd92cca7062eae28a@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] 'Waiting on lock'  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] 'Waiting on lock'  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-patches
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?

there's concensus in adding a WAIT clause?

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

pgsql-patches by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: ilike multi-byte pattern cache
Next
From: ITAGAKI Takahiro
Date:
Subject: Thread-safe PREPARE in ecpg