commit ebbb52dd62ed7796cb3f0a2a33fbe6d33de3150a Author: Simon Riggs Date: Thu Mar 24 12:08:25 2022 +0000 Test concurrent UPDATE version of read-write-unique-4.spec diff --git a/src/test/isolation/expected/read-write-unique-5.out b/src/test/isolation/expected/read-write-unique-5.out new file mode 100644 index 0000000000..179a17bd19 --- /dev/null +++ b/src/test/isolation/expected/read-write-unique-5.out @@ -0,0 +1,49 @@ +Parsed test spec with 2 sessions + +starting permutation: r1 r2 w1 w2 c1 c2 +step r1: SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; +coalesce +-------- + 3 +(1 row) + +step r2: SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; +coalesce +-------- + 3 +(1 row) + +step w1: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step w2: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step c1: COMMIT; +step w2: <... completed> +ERROR: could not serialize access due to concurrent update +step c2: COMMIT; + +starting permutation: r1 w1 w2 c1 c2 +step r1: SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; +coalesce +-------- + 3 +(1 row) + +step w1: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step w2: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step c1: COMMIT; +step w2: <... completed> +ERROR: could not serialize access due to concurrent update +step c2: COMMIT; + +starting permutation: r2 w1 w2 c1 c2 +step r2: SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; +coalesce +-------- + 3 +(1 row) + +step w1: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step w2: UPDATE invoice SET invoice_number = 3 WHERE year = 2016; +step c1: COMMIT; +step w2: <... completed> +ERROR: could not serialize access due to concurrent update +step c2: COMMIT; diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule index 8e87098150..04d9e87021 100644 --- a/src/test/isolation/isolation_schedule +++ b/src/test/isolation/isolation_schedule @@ -5,6 +5,7 @@ test: read-write-unique test: read-write-unique-2 test: read-write-unique-3 test: read-write-unique-4 +test: read-write-unique-5 test: simple-write-skew test: receipt-report test: temporal-range-integrity diff --git a/src/test/isolation/specs/read-write-unique-5.spec b/src/test/isolation/specs/read-write-unique-5.spec new file mode 100644 index 0000000000..e34e93ad98 --- /dev/null +++ b/src/test/isolation/specs/read-write-unique-5.spec @@ -0,0 +1,48 @@ +# Read-write-unique test. +# Implementing a gapless sequence of ID numbers for each year. + +setup +{ + CREATE TABLE invoice ( + year int, + invoice_number int, + PRIMARY KEY (year) + ); + + INSERT INTO invoice VALUES (2016, 2); +} + +teardown +{ + DROP TABLE invoice; +} + +session s1 +setup { BEGIN ISOLATION LEVEL SERIALIZABLE; } +step r1 { SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; } +step w1 { UPDATE invoice SET invoice_number = 3 WHERE year = 2016; } +step c1 { COMMIT; } + +session s2 +setup { BEGIN ISOLATION LEVEL SERIALIZABLE; } +step r2 { SELECT COALESCE(MAX(invoice_number) + 1, 1) FROM invoice WHERE year = 2016; } +step w2 { UPDATE invoice SET invoice_number = 3 WHERE year = 2016; } +step c2 { COMMIT; } + +# if they both read first then there should be an SSI conflict +permutation r1 r2 w1 w2 c1 c2 + +# cases where one session doesn't explicitly read before writing: + +# if s2 doesn't explicitly read, then trying to insert the value +# generates a unique constraint violation after s1 commits, as if s2 +# ran after s1 +permutation r1 w1 w2 c1 c2 + +# if s1 doesn't explicitly read, but s2 does, then s1 inserts and +# commits first, should s2 experience an SSI failure instead of a +# unique constraint violation? there is no serial order of operations +# (s1, s2) or (s2, s1) where s1 succeeds, and s2 doesn't see the row +# in an explicit select but then fails to insert due to unique +# constraint violation +permutation r2 w1 w2 c1 c2