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: 'Kyotaro HORIGUCHI' <horiguchi.kyotaro@lab.ntt.co.jp>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>
Cc: "coelho@cri.ensmp.fr" <coelho@cri.ensmp.fr>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, "michael@paquier.xyz" <michael@paquier.xyz>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-03-28T05:47:10Z
Lists: pgsql-hackers 
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> +    if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
> +             (char *) &timeout, sizeof(timeout)) < 0 && errno !=
> ENOPROTOOPT)
> +    {
> +        char        sebuf[256];
> +
> +        appendPQExpBuffer(&conn->errorMessage,
> +                    libpq_gettext("setsockopt(TCP_USER_TIMEOUT)
> failed: %s\n"),
> 
> I suppose that the reason ENOPROTOOPT is excluded from error
> condition is that the system call may fail with that errno on
> older kernels, but I don't think that that justifies ignoring the
> failure.

I think that's for the case where the modules is built on an OS that supports TCP_USER_TIMEOUT (#ifdef TCP_USER_TIMEOUT is true), and the module is used on an older OS that doesn't support TCP_USER_TIMEOUT.  I remember I was sometimes able to do such a thing on Linux and Solaris.  If we don't have to handle such usage, I agree about removing the special handling of ENOTPROTO.


Regards
Takayuki Tsunakawa

Commits

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