Tom Lane wrote: > 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 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.
Well, they have statement_timeout to prevent a command from taking too long, so that obviously isn't the usage case for NO WAIT. The problem I see for statement_timeout emulating NO WAIT is that on a lightly loaded machine, the usual query time is different from a loaded machine, so guessing a number seems difficult. Saying "Oh, the query is taking longer than X seconds, I must be waiting on a lock" is prone to failure. And if you get a faster machine or have an app that runs on machines of different speeds, it doesn't work either. One idea would be to allow the NOWAIT take a duration like statement_timeout so you could say I only want to wait a maximum of X ms before failing. However, if the usage case for NOWAIT is for an applicaiton to return a string saying "Record Locked", a GUC variable will not work and we have to be fine-grained about it as you suggest. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]