On Thu, Aug 22, 2019 at 1:45 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > > > 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.
Asim submitted this framework just yesterday: https://www.postgresql.org/message-id/CANXE4TdxdESX1jKw48xet-5GvBFVSq=4cgneiotqff372ko...@mail.gmail.com -- Rob > > 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
