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
