Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jCndq-0003wO-Ub
	for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2020 16:58:35 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jCndp-0003rZ-Ml
	for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2020 16:58:33 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jCndp-0003rS-Dr
	for pgsql-hackers@lists.postgresql.org; Fri, 13 Mar 2020 16:58:33 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jCndn-0003O4-6O
	for pgsql-hackers@postgresql.org; Fri, 13 Mar 2020 16:58:33 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 02DGwPK9030451;
	Fri, 13 Mar 2020 12:58:25 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        Andres Freund <andres@anarazel.de>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add an optional timeout clause to isolationtester step.
In-reply-to: <20200313162520.GA80899@nol>
References: <24078.1583958800@sss.pgh.pa.us>
 <20200311205254.GA2648@alvherre.pgsql> <20200313090450.6crpgoula5nrgadl@nol>
 <32140.1584108740@sss.pgh.pa.us> <20200313162520.GA80899@nol>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Fri, 13 Mar 2020 17:25:20 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30449.1584118705.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Mar 2020 12:58:25 -0400
Message-ID: <30450.1584118705@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

Julien Rouhaud <rjuju123@gmail.com> writes:
> It seems that for all the possibly interesting cases, what we want to wa=
it on
> is an heavyweight lock, which is already what isolationtester detects.  =
Maybe
> we could simply implement something like

> step "<name>" [ WAIT UNTIL BLOCKED ] { <SQL> }

> without any change to the blocking detection function?

Um, isn't that the existing built-in behavior?

I could actually imagine some uses for the reverse option, *don't* wait
for it to become blocked but just immediately continue with issuing
the next step.

			regards, tom lane