From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema <Jelte.Fennema@microsoft.com>
cc: Andres Freund <andres@anarazel.de>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        Zhihong Yu <zyu@yugabyte.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout,
 connect_timeout and keepalive settings
In-reply-to: 
 <AM5PR83MB01780E7649EC5802643666A5F7589@AM5PR83MB0178.EURPRD83.prod.outlook.com>
References: 
 <AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <CALNJ-vSbOyVm9nk3y1UwA3e+M8atwJtTg_3ugRfC5W+TyAbMZQ@mail.gmail.com>
 <AM5PR83MB01781C8E94AEC8073B646872F7B09@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <AM5PR83MB0178586E6B079DF8E7F0D855F7B09@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <b79defeb-e938-2840-8adf-fa0af08e2c2b@oss.nttdata.com>
 <1473763.1636578406@sss.pgh.pa.us>
 <HE1PR83MB0186173FC957C2554D0A31B6F7939@HE1PR83MB0186.EURPRD83.prod.outlook.com>
 <AM5PR83MB0178DCFFC1BE77C4C390DA89F7439@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <20220105184225.5xfekapzg5o3uq7a@alap3.anarazel.de>
 <794237.1641408889@sss.pgh.pa.us>
 <AM5PR83MB01782D9A7D607B0419B3CB47F74C9@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <2912315.1641943641@sss.pgh.pa.us> <2918809.1641947968@sss.pgh.pa.us>
 <2937814.1641960929@sss.pgh.pa.us>
 <AM5PR83MB017876B0409F0F6773A2174CF7529@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <144978.1642451980@sss.pgh.pa.us> <AM5PR83MB01780E7649EC5802!
 643666A5F7589@AM5PR83MB0178.EURPRD83.prod.outlook.com>
Comments: In-reply-to Jelte Fennema <Jelte.Fennema@microsoft.com>
	message dated "Tue, 18 Jan 2022 00:35:36 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <330588.1642530775.1@sss.pgh.pa.us>
Date: Tue, 18 Jan 2022 13:32:55 -0500
Message-ID: <330589.1642530775@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/330589.1642530775%40sss.pgh.pa.us>
Precedence: bulk

Jelte Fennema <Jelte.Fennema@microsoft.com> writes:
> It seems the man page of TCP_USER_TIMEOUT does not align with 
> reality then. When I use it on my local machine it is effectively used
> as a connection timeout too.

Huh, I should have thought to try that.  I confirm this behavior
on RHEL8 (kernel 4.18.0).  Not the first mistake I've seen in
Linux man pages :-(.

Doesn't seem to help on macOS, but AFAICT that platform doesn't
have TCP_USER_TIMEOUT, so no surprise there.

Anyway, that removes my objection, so I'll proceed with committing.
Thanks for working on this patch!

			regards, tom lane