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

From Bruce Momjian
Subject Re: [PATCHES] NO WAIT ...
Date
Msg-id 200402181856.i1IIuEH23831@candle.pha.pa.us
Whole thread Raw
Responses Re: [PATCHES] NO WAIT ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] NO WAIT ...  (Larry Rosenman <ler@lerctr.org>)
Re: [PATCHES] NO WAIT ...  (Rod Taylor <pg@rbt.ca>)
Re: [PATCHES] NO WAIT ...  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Tom Lane wrote:
> Hans-Jürgen Schönig <postgres@cybertec.at> writes:
> > The problem with adding NO WAIT to specific commands is that is 
> > inheritly unflexible. I think this is why the community has agreed on 
> > implementing it based on GUC.
> 
> I recall no such agreement ... when was this exactly?  In any case
> Bruce's recent complaints about regex_flavor have altered my opinions
> about GUC variables a bit.  They are bigger safety risks than they look,
> especially ones that change semantics and are intended to be modified on
> the fly.
> 
> > Do you think it would help to reduce the GUCs flexibility by reducing 
> > the lock levels a user is allowed to define?
> 
> I will vote against the patch no matter what, but I agree that it would
> be less dangerous if it were confined to only apply to a limited set of
> lock types.

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

If there is no one except Tom, we can continue.

--  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: [SQL] 7.4 - FK constraint performance
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] NO WAIT ...