Re: Cleanup isolation specs from unused steps

On Thu, Aug 22, 2019 at 12:47 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-Aug-21, Melanie Plageman wrote:
>
> > In Greenplum, we mainly add new tests to a separate isolation
> > framework (called isolation2) which uses a completely different
> > syntax. It doesn't use isolationtester at all. So, I haven't had a use
> > case to add long options to isolationtester yet :)
>
> Is that other framework somehow more capable?
>

The ability to declare a step as blocking, as Melanie mentioned upthread ("&" prefix), makes it more capable.  The tester, when encounters such a step, makes sure that the command in that step is blocking and moves on to run subsequent commands.  The isolationtester, on the other hand, treats a step as blocking only when the command waits on a lock.  That seems restrictive.  E.g. what if a command waits on a latch, as part of a valid interleaving of concurrent transactions?  The isolation tester cannot detect such a case and it will keep waiting and eventually fail the test with a timeout.

As part of the fault injector patch set [1], I added a new "blocking" keyword to isolation grammar so that a step can be declared as blocking.  See patch 0002-Add-syntax-to-declare-a-step-that-is-expected-to-block.