On Thu, Aug 22, 2019 at 6:53 PM Michael Paquier <michael@paquier.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.