Re: Cleanup isolation specs from unused steps

On Thu, Aug 22, 2019 at 6:53 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Aug 22, 2019 at 10:20:48AM -0700, Melanie Plageman wrote:
> > 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.
>
> What is "utility mode"?
>

It's a connection parameter that allows you to connect to a single Postgres
node
in a Greenplum cluster. I only included it as an example of the kind of
"Greenplum-specific" things that are in the test framework.

>
> > 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
>
> These could be transposed as new meta commands for the existing
> specs? Of course not as "step" per-se, but new dedicated commands?
>
>
Yes, I think you could definitely add some of the flags as meta-commands for
existing steps -- the current implementation of "blocking" for isolation is
really limiting.
However, features aside, I actually find the existing "step" syntax in
isolation
clunkier than the syntax used in Greenplum's "isolation2" framework.

> > See the script [1] for parsing the test cases for more details on the
> > syntax and capabilities (it is in Python).
>
> Hmm. The bar to add a new hard language dependency in the test
> suites is very high. I am not sure that we'd want something with a
> python dependency for the tests, also knowing how Python likes
> breaking compatibility (isolation2_main() also mentions a dependency
> to Python).
>

Agreed, I don't think it needs to be in Python.

My point was that some of our "isolation2" framework has to be different
because
it is enabling us to test features that are in Greenplum and not in
Postgres.
However, many of the features it has would actually be really handy to have
for
testing Postgres.
It wasn't initially suggested upstream because it is actually mainly ported
from
a separate standalone testing framework that was written at Greenplum in
Python.

I've heard Greenplum folks talk about re-writing our "isolation2" framework
in
(probably) C and making it a better fit to contribute. It's definitely on
my wishlist.

--
Melanie Plageman