Re: timeout on lock feature - Mailing list pgsql-hackers

On Wed, Apr 18, 2001 at 09:54:11AM +0200, Zeugswetter Andreas SB 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.
> 
> 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"

Many things that are easy to say have complicated consequences.

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

Exactly.  I'm talking about useful, meaningful timeouts, not random
timeouts attached to invisible events within the database.

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

No.  You wrote elsewhere that the application sets "30 seconds" and
leaves it.  But that 30 seconds doesn't have any application-level
meaning -- an operation could take twelve hours without tripping your
30-second timeout.  For the application to dictate the timeouts
reasonably, PG would have to expose all its lock events to the client
and expect it to deduce how they affect overall behavior.

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

It is good for the program to be more complicated if it is doing a 
more complicated thing -- if it means the database may remain simple.  
People building complex systems have an even greater need for simple
components than people building little ones. 
What might be a reasonable alternative would be a BEGIN timeout: report 
failure as soon as possible after N seconds unless the timer is reset, 
such as by a commit.  Such a timeout would be meaningful at the 
database-interface level.  It could serve as a useful building block 
for application-level timeouts when the client environment has trouble 
applying timeouts on its own.

Nathan Myers
ncm@zembu.com