Re: AW: AW: timeout on lock feature

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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