Re: Add an optional timeout clause to isolationtester step. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add an optional timeout clause to isolationtester step.
Date
Msg-id 20200312074941.GB1739@paquier.xyz
Whole thread Raw
In response to Re: Add an optional timeout clause to isolationtester step.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Add an optional timeout clause to isolationtester step.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 11, 2020 at 05:52:54PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-11, Tom Lane wrote:
>> We could re-use Julien's ideas about the isolation spec syntax by
>> making it be, roughly,
>>
>> step "<name>" { <SQL> } [ blocked if "<wait_event_type>" "<wait_event>" ]
>>
>> and then those items would need to be passed as parameters of the prepared
>> query.
>
> I think for test readability's sake, it'd be better to put the BLOCKED
> IF clause ahead of the SQL, so you can write it in the same line and let
> the SQL flow to the next one:
>
> STEP "long_select" BLOCKED IF "lwlock" "ClogControlLock"
>   { select foo from pg_class where ... some more long clauses ... }
>
> otherwise I think a step would require more lines to write.

I prefer this version.

>> I'd like to see an attempt to rewrite some of the existing
>> timeout-dependent test cases to use this facility instead of
>> long timeouts.  If we could get rid of the timeouts in the
>> deadlock tests, that'd go a long way towards showing that this
>> idea is actually any good.
>
> +1.  Those long timeouts are annoying enough that infrastructure to make
> a run shorter in normal circumstances might be sufficient justification
> for this patch ...

+1.  A patch does not seem to be that complicated.  Now isn't it too
late for v13?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)
Next
From: David Rowley
Date:
Subject: Re: [PATCH] Erase the distinctClause if the result is unique by definition