Re: Timeout parameters

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>
Cc: "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, 'Fabien COELHO' <coelho@cri.ensmp.fr>, 'Kyotaro HORIGUCHI' <horiguchi.kyotaro@lab.ntt.co.jp>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-04-05T07:05:40Z
Lists: pgsql-hackers
On Fri, Apr 05, 2019 at 04:39:36AM +0000, Jamison, Kirk wrote:
> I just checked and confirmed that the TCP USER TIMEOUT patch set v20
> works.  Although you should capitalize "linux" to "Linux" as already
> mentioned before.  The committer can also just fix that very minor
> part, if patch is deemed committable.

The first letter should be upper-case.  

> Note to committer: The "Ready for Committer" status is mainly intended for
> tcp user timeout parameter.
> 
> OTOH, unless there is consensus with the socket_timeout,
> for now the socket_timeout patch status still remains as "Needs Review".

I was looking at the patch set a couple of days ago.  The proposed
TCP_backend_v20.patch and TCP_interface_v20.patch make sense, but it
seems to me that socket_timeout_v14.patch should be rejected as it
could cause a connection to go down with no actual reason and that
the server should be in charge of handling timeouts.  Is my impression
right?
--
Michael

Commits

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