On Wed, Aug 21, 2019 at 12:16 PM Alvaro Herrera <alvhe...@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