Thread: Re: [PATCHES] NO WAIT ...

> > 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.

Andreas

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
 

> 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).

Wrote one program a while ago that was very time sensitive. By the time
deadlock detection had been kicked off, the data was already invalid and
due to be replaced -- thus, it's impossible to have deadlocks with the
chosen design for that application.


The point is, PostgreSQL is fairly versatile and is a component of many
different environments. Method X might be great for what you're doing,
but it doesn't apply across the board.

The regex GUC doesn't impact a majority of applications either, but it
proved catastrophic to some.

On Thu, 2004-02-19 at 11:01, Bruce Momjian wrote:
> 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.
> 

Is it premature to add "allow vacuum command to use no wait semantics on
locks" to the TODO list?

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL