Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> The timeout will be useful to let the client or user decide on an
> alternate course of action other that killing his application (without
> the need for timers or threads in the client program).
Okay, let's take a close look at this assumption.
1. Why is 10 seconds (or 1, or 30) a magic number? If you've waited
that long, why wouldn't you be willing to wait a little longer? How
will you know what value to pick?
2. If you do want a timeout to support an interactive application, seems
to me that you want to specify it as a total time for the whole query,
not the maximum delay to acquire any individual lock. Under normal
circumstances lock delays are likely to be just a small part of total
query time.
3. Since we already have deadlock detection, there is no need for
timeouts as a defense against deadlock. A timeout would only be useful
to defend against other client applications that are sitting idle or
executing long-running operations while holding locks that conflict
with your real-time query. This scenario strikes me as a flaw in the
overall application design, which should be fixed by fixing those other
clients and/or the lock usage. A lock timeout is just a bandaid
to cope (poorly) with broken application design.
4. The correct way to deal with overly-long queries in an interactive
application is to let the user interactively cancel queries (which we
already support). This is much better than any application-specified
fixed timeout, because the application is unlikely to be aware of
extenuating circumstances --- say, the system is heavily overloaded at
the moment because of lots of activity. I can think of few things more
annoying than an application-set timeout that kills my unfinished query
whenever the system is under load.
In short, I think lock timeout is a solution searching in vain for a
problem. If we implement it, we are just encouraging bad application
design.
regards, tom lane
