From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
cc: 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>,
        pgsql-hackers@lists.postgresql.org,
        Etsuro Fujita <etsuro.fujita@gmail.com>
Subject: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
In-reply-to: 
 <CAGECzQRkiiGQC+ne57ZhZv-dcQ3k5Ey4BjwXpiUKsWQ=9vftfg@mail.gmail.com>
References: 
 <CAGECzQRsdWnj=YaaPCnA8d7E1AdbxRPBYmyBQRMPUijR2MpM_w@mail.gmail.com>
 <202403281643.vinbx2b56s6h@alvherre.pgsql>
 <CAGECzQRkiiGQC+ne57ZhZv-dcQ3k5Ey4BjwXpiUKsWQ=9vftfg@mail.gmail.com>
Comments: In-reply-to Jelte Fennema-Nio <postgres@jeltef.nl>
	message dated "Thu, 28 Mar 2024 18:13:56 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3640450.1711647346.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Mar 2024 13:35:46 -0400
Message-ID: <3640451.1711647346@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3640451.1711647346%40sss.pgh.pa.us>
Precedence: bulk

Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> On Thu, 28 Mar 2024 at 17:43, Alvaro Herrera <alvherre@alvh.no-ip.org> w=
rote:
>> Hah, you're right, I can reproduce with a smaller timeout, and using SE=
T
>> LOCAL works as a fix.  If we're doing that, why not reduce the timeout
>> to 1ms?  We don't need to wait extra 9ms ...

> I think we don't really want to make the timeout too short. Otherwise
> the query might get cancelled before we push any query down to the
> FDW. I guess that means that for some slow machines even 10ms is not
> enough to make the test do the intended purpose. I'd keep it at 10ms,
> which seems long enough for normal systems, while still being pretty
> short.

If the test fails both when the machine is too slow and when it's
too fast, then there's zero hope of making it stable and we should
just remove it.

			regards, tom lane