AW: timeout on lock feature

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

In interactive OLTP it does.

> -- an operation could take twelve hours without tripping your
> 30-second timeout.

Not in OLTP. Using the feature for a batch client with a low timeout
would be plain wrong.

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

I like that, but I do not think it is feasible. 

I do not think that you can guarantee an answer within x seconds,
be it positive or negative. But that is what this feature would imply.
If the client needs to react within x sec there is no way around implementing this in 
the client (there could be all kinds of trouble between client and backend). 

On a very busy server (in OLTP that is the only real reason your query takes too 
long other than waiting for a lock) you will produce still more work with this feature.
That is also partly why I think that a lock timeout feature really makes sense
for interactive OLTP clients. It is not a perfect solution, but it usually serves
the purpose very well and keeps the client simple. And I do not agree, that it
is an objective to keep the db code simple at the cost of making a standard client
more complex. 

Andreas