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
-
Add support TCP user timeout in libpq and the backend server
- 249d64999615 12.0 landed