Re: Regression tests vs SERIALIZABLE

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2021-03-17T04:28:28Z
Lists: pgsql-hackers
On Tue, Mar 16, 2021 at 3:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Mon, Mar 15, 2021 at 5:24 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> >> However, since commit 862ef372d6b, there *is* one test that fails if
> >> you run make installcheck against a cluster running with -c
> >> default_transaction_isolation=serializable: transaction.sql.  Is that
> >> a mistake?  Is it a goal to be able to run this test suite against all
> >> 3 isolation levels?
>
> > Here's a fix.
>
> Usually, if we issue a SET in the regression tests, we explicitly RESET
> as soon thereafter as practical, so as to have a well-defined scope
> where the script is running under unusual conditions.

Oh, of course.  Thanks.

I was wrong to blame that commit, and there are many other tests that
fail in the back branches.  But since we were down to just one, I went
ahead and fixed this in the master branch only.



Commits

  1. Fix transaction.sql tests in higher isolation levels.

  2. Drop SERIALIZABLE workaround from parallel query tests.

  3. Fix behavior of AND CHAIN outside of explicit transaction blocks

  4. Enable parallel query with SERIALIZABLE isolation.