> > 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.
>
> I agree with Tom completely here.
>
> In any real-world application the database is the key component of a
> larger system: the work it does is the most finicky, and any mistakes
> (either internally or, more commonly, from misuse) have the most
> far-reaching consequences. The responsibility of the database is to
> provide a reliable and easily described and understood mechanism to
> build on.
It is not something that makes anything unrelyable or less robust.
It is also simple: "I (the client) request that you (the backend) dont wait for
any lock longer than x seconds"
> Timeouts are a system-level mechanism that to be useful must refer to
> system-level events that are far above anything that PG knows about.
I think you are talking about different kinds of timeouts here.
> The only way PG could apply reasonable timeouts would be for the
> application to dictate them,
That is exactly what we are talking about here.
> but the application can better implement them itself.
It can, but it makes the program more complicated (needs timers or threads,
which violates your last statement "simplest interface".
>
> You can think of this as another aspect of the "end-to-end" principle:
> any system-level construct duplicated in a lower-level system component
> can only improve efficiency, not provide the corresponding high-level
> service. If we have timeouts in the database, they should be there to
> enable the database to better implement its abstraction, and not pretend
> to be a substitute for system-level timeouts.
Mentioned functionality has nothing to do with above statement which
I can fully support.
> There's no upper limit on how complicated a database interface can
> become (cf. Oracle). The database serves its users best by having
> the simplest interface that can possibly provide the needed service.
Agreed.
Andreas
