Re: Implementing setQueryTimeout()
От | Oliver Jowett |
---|---|
Тема | Re: Implementing setQueryTimeout() |
Дата | |
Msg-id | 47BA470A.8000904@opencloud.com обсуждение исходный текст |
Ответ на | Re: Implementing setQueryTimeout() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Implementing setQueryTimeout()
Re: Implementing setQueryTimeout() |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: