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

From Bruce Momjian
Subject Re: [PATCHES] NO WAIT ...
Date
Msg-id 200402182142.i1ILgEe15582@candle.pha.pa.us
Whole thread Raw
In response to Re: [PATCHES] NO WAIT ...  (Barry Lind <blind@xythos.com>)
List pgsql-hackers
TODO updated:
< * Add GUC variable to prevent waiting on locks> * Add NO WAIT option to various SQL commands


---------------------------------------------------------------------------

Barry Lind wrote:
> I agree with Tom here.  I have used the Oracle NOWAIT feature in the 
> past and think it is a great feature IMHO.  But when you need to use it, 
> you want it to apply very specifically to a single statement.  Using a 
> sledge hammer when you need a tweezers isn't the right way to go.
> 
> thanks,
> --Barry
> 
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > 
> >>The question is whether we should have a GUC variable to control no
> >>waiting on locks or add NO WAIT to specific SQL commands.
> > 
> > 
> > That's only a minor part of the issue.  The major problem I have with
> > the patch is that it affects *all* locks, including system-internal
> > lock attempts that the user is probably not even aware of much less
> > able to control.  It's like giving someone a poorly-aligned shotgun
> > when what they need is a rifle --- they'll end up putting holes in
> > a lot of other things besides what they intended.
> > 
> > I think that what we actually want is something that is narrowly
> > tailored to affect only row-level locks taken by SELECT FOR UPDATE,
> > and maybe one or two other places that (a) people can make specific
> > use-cases for, and (b) we can be certain are only invoked by user
> > commands and never indirectly from behind-the-scenes system operations.
> > 
> > The reason for proposing syntax rather than a GUC variable is the same
> > one of control.  If you set a GUC variable then it will be hard to
> > prevent it from breaking operations other than the one you thought you
> > intended.  (Example: you think you are only causing your SELECT FOR
> > UPDATE to error out, but what about ones done behind the scenes for
> > foreign key checks?)  GUC variables are good for stuff that tends to
> > apply application-wide, which is why I thought regex_flavor wasn't too
> > dangerous, but they're terrible for functions that you want to apply to
> > only certain specific operations.  And I can't imagine an app where that
> > wouldn't be true for NO WAIT.
> > 
> >             regards, tom lane
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> > 
> >                http://www.postgresql.org/docs/faqs/FAQ.html
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

--  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: Bruce Momjian
Date:
Subject: Re: [PATCHES] NO WAIT ...
Next
From: Jan Wieck
Date:
Subject: Re: [PATCHES] NO WAIT ...