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

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.

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 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