Date: Fri, 29 Mar 2024 15:17:24 -0700
From: Noah Misch <noah@leadboat.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>,
	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
Message-ID: <20240329221724.03@rfd.leadboat.com>
References: <202403281753.ku5k2jvaw5fo@alvherre.pgsql>
 <3643677.1711648979@sss.pgh.pa.us>
 <CAGECzQRqxwcaePLd3MmpZ380CRiCrzPAwmGXsUY9jR5EWf5DLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAGECzQRqxwcaePLd3MmpZ380CRiCrzPAwmGXsUY9jR5EWf5DLg@mail.gmail.com>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20240329221724.03%40rfd.leadboat.com>
Precedence: bulk

On Fri, Mar 29, 2024 at 09:17:55AM +0100, Jelte Fennema-Nio wrote:
> On Thu, 28 Mar 2024 at 19:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Could we make this test bulletproof by using an injection point?
> > If not, I remain of the opinion that we're better off without it.
> 
> Possibly, and if so, I agree that would be better than the currently
> added test. But I honestly don't feel like spending the time on
> creating such a test.

The SQL test is more representative of real applications, and it's way simpler
to understand.  In general, I prefer 6-line SQL tests that catch a problem 10%
of the time over injection point tests that catch it 100% of the time.  For
low detection rate to be exciting, it needs to be low enough to have a serious
chance of all buildfarm members reporting green for the bad commit.  With ~115
buildfarm members running in the last day, 0.1% detection rate would have been
low enough to bother improving, but 4% would be high enough to call it good.