Re: An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Mon, Jan 16, 2017 at 10:37 PM, Craig Ringer
<craig(dot)ringer(at)2ndquadrant(dot)com> wrote:
> On 16 Jan. 2017 17:09, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
>
> On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> I also have longer term plans to show the first and third of them
>> running with the read-only transaction moved to a standby server.
>> Kevin Grittner gave me the idea of multi-server isolation tests when I
>> mentioned my WIP SERIALIZABLE DEFERRABLE-on-standbys patch off-list,
>
> Being able to do that with the isolation tester has been mentioned a
> coupled of times, particularly from 2ndQ folks who worked in BDR. I
> think that it has been actually patched in this sense, so perhaps you
> could reuse the work that has been done there.
>
>
> Yep. See the bdr-pg/REL9_4_STABLE branch of the BDR repo, src/test/isolation
> .
>
> I think Abhijit submitted a patch to the list too.

Very nice. That's almost exactly what I had in mind. One thing that
jumps out at me from README.multinode is that it's surprising to see
conninfo strings in the actual spec file: I assumed that the isolation
tester would extend what it does today by accepting multiple conninfo
command line arguments, and I imagined that the spec info could say
something like SESSION "s3" CONNECTION 2. I don't really care about
names vs numbers but I thought it might be nice if connections were
controlled separately from specs so that you could use the same spec
for tests that are run on one node and two node setups, perhaps by
making CONNECTION 2 fall back to the default connection if there is no
connection 2 provided on the command line. For example, with
read-only-anomaly.spec (from the patch in this thread), the output
should be identical if you point s3 at a standby using syncrep and
remote_apply. In future, if SERIALIZABLE DEFERRABLE is available on
standbys, then read-only-anomaly-3.spec should also work that way.
It'd be cool to find a way to express that without having to use a
separate spec/expected files for the multi-node version when the goal
is to show that it works the same as the single-node version.

--
Thomas Munro
http://www.enterprisedb.com