| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com> |
| Cc: | "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Timeout parameters |
| Date: | 2019-04-05 07:05:40 |
| Message-ID: | 20190405070540.GC31003@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-04-05 07:10:15 | Re: [HACKERS] Block level parallel vacuum |
| Previous Message | Michael Paquier | 2019-04-05 06:58:03 | Re: Re: A separate table level option to control compression |