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
