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