AW: timeout on lock feature

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