From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
cc: Alexander Lakhin <exclusion@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Noah Misch <noah@leadboat.com>,
        Jacob Champion <jacob.champion@enterprisedb.com>,
        Denis Laxalde <denis.laxalde@dalibo.com>,
        vignesh C <vignesh21@gmail.com>,
 Thomas Munro <thomas.munro@gmail.com>,
        Greg Stark <stark@mit.edu>,
        "Gregory Stark (as CFM)" <stark.cfm@gmail.com>,
        Jelte Fennema <Jelte.Fennema@microsoft.com>,
        Daniel Gustafsson <daniel@yesql.se>,
        Peter Eisentraut <peter@eisentraut.org>,
        Andres Freund <andres@anarazel.de>,
        Justin Pryzby <pryzby@telsasoft.com>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Etsuro Fujita <etsuro.fujita@gmail.com>
Subject: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
In-reply-to: <584811.1725048717@sss.pgh.pa.us>
References: <202407221126.vyw5q3h4nyoh@alvherre.pgsql>
 <5ea25e4d-1ee2-b9bf-7806-119ffa658826@gmail.com>
 <578934.1725045685@sss.pgh.pa.us>
 <CAGECzQQZi_po92DSgo75vmM-KxG2zMGzo-tt+Z+85w3BgL89ug@mail.gmail.com>
 <584811.1725048717@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 30 Aug 2024 16:11:57 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <591892.1725051309.1@sss.pgh.pa.us>
Date: Fri, 30 Aug 2024 16:55:09 -0400
Message-ID: <591893.1725051309@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/591893.1725051309%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Hmm.  I'm not convinced that 0001 is an actual *fix*, but it should
> at least reduce the frequency of occurrence a lot, which'd help.

After enabling log_statement = all to verify what commands are being
sent to the remote, I realized that there's a third thing this patch
can do to stabilize matters: issue a regular remote query inside the
test transaction, before we enable the timeout.  This will ensure
that we've dealt with configure_remote_session() and started a
remote transaction, so that there aren't extra round trips happening
for that while the clock is running.

Pushed with that addition and some comment-tweaking.  We'll see
whether that actually makes things more stable, but I don't think
it could make it worse.

			regards, tom lane