Bruce Momjian <[EMAIL PROTECTED]> 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 absolutely agree to that.
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.
I would gereralize this to user table row level and explicit lock table. There is no need to force a separate SELECT FOR UPDATE in front of every UPDATE or DELETE attempt in order to achieve the desired nolock behaviour.
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.
This all needs a lot more detail than it has so far. If one tries to UPDATE a row with NOLOCK, and a trigger fired during this would block on the attempt to create a temp table, I think the resulting transaction abort would rather be reported as a bug to us, then accepted as a nice feature.
If there is a call for vote, I vote against.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
