Re: Cleanup isolation specs from unused steps - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Cleanup isolation specs from unused steps
Date
Msg-id CAAKRu_aZfa8pBKeLrGcrL42H9-VOU9m10ZFvWrbiiccsKQ7X0A@mail.gmail.com
Whole thread Raw
In response to Re: Cleanup isolation specs from unused steps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Cleanup isolation specs from unused steps
Re: Cleanup isolation specs from unused steps
List pgsql-hackers

On Wed, Aug 21, 2019 at 12:16 PM 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?

So, there is some historical context as to why it is a separate test suite.
And some of the differences are specific to Greenplum -- e.g. needing to connect
to a specific database in "utility mode" to do something.

However, the other differences are actually pretty handy and would be applicable
to upstream as well.
We use a different syntax than the isolation framework and have some nice
features. Most notably, explicit control over blocking.

The syntax for what would be a "step" in isolation is like this:

[<#>[flag]:] <sql> | ! <shell scripts or command>

where # is the session number and flags include the following:

&: expect blocking behavior
>: running in background without blocking
<: join an existing session
q: quit the given session

See the script [1] for parsing the test cases for more details on the syntax and
capabilities (it is in Python).

[1] https://github.com/greenplum-db/gpdb/blob/master/src/test/isolation2/sql_isolation_testcase.py

--
Melanie Plageman

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: Tom Lane
Date:
Subject: Preserving extension ownership in dump/restore/pg_upgrade