Re: [PATCHES] NO WAIT ... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] NO WAIT ...
Date
Msg-id 200402191601.i1JG1m820902@candle.pha.pa.us
Whole thread Raw
In response to Re: [PATCHES] NO WAIT ...  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: [PATCHES] NO WAIT ...  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
Zeugswetter Andreas SB SD wrote:
> 
> > > The question is whether we should have a GUC variable to control no
> > > waiting on locks or add NO WAIT to specific SQL commands.
> > > 
> > > Does anyone want to vote _against_ the GUC idea for nowait locking.  (We
> > > already have two voting for such a variable.)
> > 
> > I vote against. We got bit by both the regex and the autocommit GUC vars
> > and this is setting up to cause a similar headache with old code on new
> > platforms.
> 
> I vote for the GUC. Imho it is not comparable to the "autocommit" case,
> since it does not change the way your appl needs to react (appl needs to
> react to deadlock already).
> 
> I personally think a wait period in seconds would be more useful.
> Milli second timeouts tend to be misused with way too low values
> in this case, imho.

I understand, but GUC lost the vote.  I have updated the TODO list to
indicate this.  Tatsuo posted a patch to add NO WAIT to the LOCK
command, so we will see if we can get that into CVS.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: OIDs, CTIDs, updateable cursors and friends
Next
From: Rod Taylor
Date:
Subject: Re: [PATCHES] NO WAIT ...