Add isolation test for SERIALIZABLE READ ONLY DEFERRABLE.

This improves code coverage and lays a foundation for testing
similar issues in a distributed environment.

Author: Thomas Munro <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>

src/test/isolation/expected/read-only-anomaly-2.out

@@ -0,0 +1,44 @@
+Parsed test spec with 3 sessions
+
+starting permutation: s2rx s2ry s1ry s1wy s1c s2wx s2c s3c
+step s2rx: SELECT balance FROM bank_account WHERE id = 'X';
+balance 
+
+0 
+step s2ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1wy: UPDATE bank_account SET balance = 20 WHERE id = 'Y';
+step s1c: COMMIT;
+step s2wx: UPDATE bank_account SET balance = -11 WHERE id = 'X';
+step s2c: COMMIT;
+step s3c: COMMIT;
+
+starting permutation: s2rx s2ry s1ry s1wy s1c s3r s3c s2wx
+step s2rx: SELECT balance FROM bank_account WHERE id = 'X';
+balance 
+
+0 
+step s2ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1wy: UPDATE bank_account SET balance = 20 WHERE id = 'Y';
+step s1c: COMMIT;
+step s3r: SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id;
+id balance 
+
+X 0 
+Y 20 
+step s3c: COMMIT;
+step s2wx: UPDATE bank_account SET balance = -11 WHERE id = 'X';
+ERROR: could not serialize access due to read/write dependencies among transactions

src/test/isolation/expected/read-only-anomaly-3.out

@@ -0,0 +1,26 @@
+Parsed test spec with 3 sessions
+
+starting permutation: s2rx s2ry s1ry s1wy s1c s3r s2wx s2c s3c
+step s2rx: SELECT balance FROM bank_account WHERE id = 'X';
+balance 
+
+0 
+step s2ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1wy: UPDATE bank_account SET balance = 20 WHERE id = 'Y';
+step s1c: COMMIT;
+step s3r: SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id; <waiting ...>
+step s2wx: UPDATE bank_account SET balance = -11 WHERE id = 'X';
+step s2c: COMMIT;
+step s3r: <... completed>
+id balance 
+
+X -11 
+Y 20 
+step s3c: COMMIT;

src/test/isolation/expected/read-only-anomaly.out

@@ -0,0 +1,25 @@
+Parsed test spec with 3 sessions
+
+starting permutation: s2rx s2ry s1ry s1wy s1c s3r s2wx s2c s3c
+step s2rx: SELECT balance FROM bank_account WHERE id = 'X';
+balance 
+
+0 
+step s2ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1ry: SELECT balance FROM bank_account WHERE id = 'Y';
+balance 
+
+0 
+step s1wy: UPDATE bank_account SET balance = 20 WHERE id = 'Y';
+step s1c: COMMIT;
+step s3r: SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id;
+id balance 
+
+X 0 
+Y 20 
+step s2wx: UPDATE bank_account SET balance = -11 WHERE id = 'X';
+step s2c: COMMIT;
+step s3c: COMMIT;

src/test/isolation/isolation_schedule

@@ -1,3 +1,6 @@
+test: read-only-anomaly
+test: read-only-anomaly-2
+test: read-only-anomaly-3
 test: read-write-unique
 test: read-write-unique-2
 test: read-write-unique-3

src/test/isolation/isolationtester.c

@@ -231,6 +231,14 @@ main(int argc, char **argv)
  appendPQExpBuffer(&wait_query, ",%s", backend_pids[i]);
  appendPQExpBufferStr(&wait_query, "}'::integer[]");
 
+ /* Also detect certain wait events. */
+ appendPQExpBufferStr(&wait_query,
+ " OR EXISTS ("
+ " SELECT * "
+ " FROM pg_catalog.pg_stat_activity "
+ " WHERE pid = $1 "
+ " AND wait_event IN ('SafeSnapshot'))");
+
  res = PQprepare(conns[0], PREP_WAITING, wait_query.data, 0, NULL);
  if (PQresultStatus(res) != PGRES_COMMAND_OK)
  {

src/test/isolation/specs/read-only-anomaly-2.spec

@@ -0,0 +1,42 @@
+# The example from the paper "A read-only transaction anomaly under snapshot
+# isolation"[1].
+#
+# Here we test that serializable snapshot isolation (SERIALIZABLE) doesn't
+# suffer from the anomaly, because s2 is aborted upon detection of a cycle.
+#
+# [1] http:https://www.cs.umb.edu/~poneil/ROAnom.pdf
+
+setup
+{
+ CREATE TABLE bank_account (id TEXT PRIMARY KEY, balance DECIMAL NOT NULL);
+ INSERT INTO bank_account (id, balance) VALUES ('X', 0), ('Y', 0);
+}
+
+teardown
+{
+ DROP TABLE bank_account;
+}
+
+session "s1"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; }
+step "s1ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s1wy" { UPDATE bank_account SET balance = 20 WHERE id = 'Y'; }
+step "s1c" { COMMIT; }
+
+session "s2"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; }
+step "s2rx" { SELECT balance FROM bank_account WHERE id = 'X'; }
+step "s2ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s2wx" { UPDATE bank_account SET balance = -11 WHERE id = 'X'; }
+step "s2c" { COMMIT; }
+
+session "s3"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; }
+step "s3r" { SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id; }
+step "s3c" { COMMIT; }
+
+# without s3, s1 and s2 commit
+permutation "s2rx" "s2ry" "s1ry" "s1wy" "s1c" "s2wx" "s2c" "s3c"
+
+# once s3 observes the data committed by s1, a cycle is created and s2 aborts
+permutation "s2rx" "s2ry" "s1ry" "s1wy" "s1c" "s3r" "s3c" "s2wx"

src/test/isolation/specs/read-only-anomaly-3.spec

@@ -0,0 +1,39 @@
+# The example from the paper "A read-only transaction anomaly under snapshot
+# isolation"[1].
+#
+# Here we test that serializable snapshot isolation can avoid the anomaly
+# without aborting any tranasctions, by instead causing s3 to be deferred
+# until a safe snapshot can be taken.
+#
+# [1] http:https://www.cs.umb.edu/~poneil/ROAnom.pdf
+
+setup
+{
+ CREATE TABLE bank_account (id TEXT PRIMARY KEY, balance DECIMAL NOT NULL);
+ INSERT INTO bank_account (id, balance) VALUES ('X', 0), ('Y', 0);
+}
+
+teardown
+{
+ DROP TABLE bank_account;
+}
+
+session "s1"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; }
+step "s1ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s1wy" { UPDATE bank_account SET balance = 20 WHERE id = 'Y'; }
+step "s1c" { COMMIT; }
+
+session "s2"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; }
+step "s2rx" { SELECT balance FROM bank_account WHERE id = 'X'; }
+step "s2ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s2wx" { UPDATE bank_account SET balance = -11 WHERE id = 'X'; }
+step "s2c" { COMMIT; }
+
+session "s3"
+setup { BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE; }
+step "s3r" { SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id; }
+step "s3c" { COMMIT; }
+
+permutation "s2rx" "s2ry" "s1ry" "s1wy" "s1c" "s3r" "s2wx" "s2c" "s3c"

src/test/isolation/specs/read-only-anomaly.spec

@@ -0,0 +1,38 @@
+# The example from the paper "A read-only transaction anomaly under snapshot
+# isolation"[1].
+#
+# Here we use snapshot isolation (REPEATABLE READ), so that s3 sees a state of
+# afairs that is not consistent with any serial ordering of s1 and s2.
+#
+# [1] http:https://www.cs.umb.edu/~poneil/ROAnom.pdf
+
+setup
+{
+ CREATE TABLE bank_account (id TEXT PRIMARY KEY, balance DECIMAL NOT NULL);
+ INSERT INTO bank_account (id, balance) VALUES ('X', 0), ('Y', 0);
+}
+
+teardown
+{
+ DROP TABLE bank_account;
+}
+
+session "s1"
+setup { BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; }
+step "s1ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s1wy" { UPDATE bank_account SET balance = 20 WHERE id = 'Y'; }
+step "s1c" { COMMIT; }
+
+session "s2"
+setup { BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; }
+step "s2rx" { SELECT balance FROM bank_account WHERE id = 'X'; }
+step "s2ry" { SELECT balance FROM bank_account WHERE id = 'Y'; }
+step "s2wx" { UPDATE bank_account SET balance = -11 WHERE id = 'X'; }
+step "s2c" { COMMIT; }
+
+session "s3"
+setup { BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; }
+step "s3r" { SELECT id, balance FROM bank_account WHERE id IN ('X', 'Y') ORDER BY id; }
+step "s3c" { COMMIT; }
+
+permutation "s2rx" "s2ry" "s1ry" "s1wy" "s1c" "s3r" "s2wx" "s2c" "s3c"