pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema <Jelte.Fennema@microsoft.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Zhihong Yu <zyu@yugabyte.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout, connect_timeout and keepalive settings
Date: Mon, 17 Jan 2022 15:39:40 -0500
Message-ID: <144978.1642451980@sss.pgh.pa.us> (raw)
In-Reply-To: <AM5PR83MB017876B0409F0F6773A2174CF7529@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>

Jelte Fennema <Jelte.Fennema@microsoft.com> writes:
> Thanks for all the cleanup and adding of windows support. To me it now looks good to merge.

I was about to commit this when I started to wonder if it actually does
anything useful.  In particular, I read in the Linux tcp(7) man page

       TCP_USER_TIMEOUT (since Linux 2.6.37)
              ...
              This option can be set during any state of a TCP connection, but
              is effective only during the synchronized states of a connection
              (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,  CLOSING,  and
              LAST-ACK).

ISTM that the case we care about is where the server fails to respond
to the TCP connection request.  If it does so, it seems pretty unlikely
that it wouldn't then eat the small amount of data we're going to send.

While the keepalive options aren't so explicitly documented, I'd bet that
they too don't have any effect until the connection is known established.

So I'm unconvinced that setting these values really has much effect
to make PQcancel more robust (or more accurately, make it fail faster).
I would like to know what scenarios you tested to convince you that
this is worth doing.

			regards, tom lane





view thread (18+ messages)  latest in thread

Message-ID: <144978.1642451980@sss.pgh.pa.us>
Permalink:  ../144978.1642451980@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/144978.1642451980@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, Jelte.Fennema@microsoft.com, andres@anarazel.de, masao.fujii@oss.nttdata.com, zyu@yugabyte.com
  Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout, connect_timeout and keepalive settings
  In-Reply-To: <144978.1642451980@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox