On Tue, Apr 17, 2001 at 12:56:11PM -0400, Tom Lane wrote:
> 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.
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.
The only way PG could apply reasonable timeouts would be for the
application to dictate them, but the application can better implement
them itself.
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.
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.
Nathan Myers
ncm@zembu.com
