Hello Ryohei-san,
> About socket_timeout:
>> From: Fabien COELHO <coelho@cri.ensmp.fr>
>> are actually finished. I cannot say that I'm thrilled by that behavior. ISTM that libpq
>> should at least attempt to cancel the query
> Would you please tell me why you think so?
As I understand the "client-side timeout" use-case, as distinct from
network-issues-related timeouts proposed in the other patches, the point
is more or less to deal with an overloaded server.
As it is currently implemented, the connection is broken abruptly when the
timeout is reached, but that the initial query goes on nevertheless
server-side, and a new connection is created which would worsens the load.
ISTM that it would be more appropriate to cancel the query and possibly
keep the connection, if possible.
> If it was implemented so, timeout couldn't work when the server is so
> busy that can't process a cancel request.
Hmmm. I do not understand how you would know that.
The timeout is raised because getting the result takes time, which may be
simply because the query really takes time, and it does not imply that the
server would not be able to process a cancel request. You could at least
send it before trying the extreme approach.
If the server is really overloaded, the current implementation does not
help in any way but contributes to worsen the situation, hence my lack of
enthousiasm.
> If the client encounters such a case, how does the client stop to wait the server?
> How does the client release its resources?
> Socket_timeout is helpful for such clients.
--
Fabien.
