Horton

RE: Timeout parameters

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Robert Haas' <robertmhaas@gmail.com>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, Michael Paquier <michael@paquier.xyz>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-03-19T04:13:40Z
Lists: pgsql-hackers 
From: Robert Haas [mailto:robertmhaas@gmail.com]
> I don't think so.  I think it's just a weirdly-design parameter
> without a really compelling use case.  Enforcing limits on the value
> of the parameter doesn't fix that.  Most of the reviewers who have
> opined so far have been somewhere between cautious and negative about
> the value of that parameter, so I think we should just not add it.  At
> least for now.

I don't think socket_timeout is so bad.  I think Nagaura-san and I presented the use case, giving an answer to every question and concern.  OTOH, it may be better to commit the tcp_user_timeout patch when Nagaura-san has refined the documentation, and then continue socket_timeout.


Regards
Takayuki Tsunakawa

Commits

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