Re: AW: AW: timeout on lock feature

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