Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
>> I'd argue that "close connection on network timeout if setQueryTimeout()
>> is set" is better than "do absolutely nothing special if
>> setQueryTimeout() is set", anyway. If you don't want queries being
>> aborted because they are taking too long to complete.. don't set a query
>> timeout!
>
> I think it's a serious, serious conceptual error to tie network timeouts
> to query timeouts.
Why? I don't understand this argument.
setQueryTimeout() is documented as:
> Sets the number of seconds the driver will wait for a Statement object to execute to the given number of seconds. If
thelimit is exceeded, an SQLException is thrown.
That would seem to cover any sort of delay, not just "it is a slow query
on the server side". If the Statement can't execute in N seconds, return
an error. That could mean slow network - slow query - whatever.
I don't see why clients that want timeouts care about the cause of the
slowness - all they care about is that they get control back within
some reasonable amount of time, surely? What's the use case where you
would use setQueryTimeout() but don't actually mean "give me control
back in N seconds"?
If a client is postgresql-aware, it could always set statement_timeout
itself if it really does mean "don't take more than N seconds of server
time" instead of "please return within N seconds".
-O