Re: Timeout parameters

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Michael Paquier <michael@paquier.xyz>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>
Date: 2019-03-13T17:25:08Z
Lists: pgsql-hackers
Hello Robert,

>> Also, I do not see the downside of sending a cancel query before severing
>> the connection. If it is not processed, too bad, but if it is then it is
>> for the better.
>
> If the network connection is dead, which is the situation the patch
> intends to detect,

Hmmm... ISTM that we are not talking about the same patch...

My point is about the "socket_timeout" patch which timeout on not 
receiving an answer, but is not related to the network connection.

The other two patches, however, deal with tcp timeout both client & server 
side, and are indeed more related to the network connection. Sending 
request on a tcp timeout would not make much sense, but this is not the 
proposal here.

> then PQcancel() isn't going to work, but it might still hang for a 
> period of time or forever.  That seems like a pretty major downside.

The fact that no answer data is received may mean that it takes time to 
compute the result, so cancelling seems appropriate to me, rather than 
severing the connection and starting a new one immediately, leaving the 
server loaded with its query.

-- 
Fabien.


Commits

  1. Add support TCP user timeout in libpq and the backend server