diff options
Diffstat (limited to 'src/test')
| -rw-r--r-- | src/test/isolation/expected/predicate-lock-hot-tuple.out | 20 | ||||
| -rw-r--r-- | src/test/isolation/isolation_schedule | 1 | ||||
| -rw-r--r-- | src/test/isolation/specs/predicate-lock-hot-tuple.spec | 37 |
3 files changed, 58 insertions, 0 deletions
diff --git a/src/test/isolation/expected/predicate-lock-hot-tuple.out b/src/test/isolation/expected/predicate-lock-hot-tuple.out new file mode 100644 index 00000000000..d1c69bbbd03 --- /dev/null +++ b/src/test/isolation/expected/predicate-lock-hot-tuple.out @@ -0,0 +1,20 @@ +Parsed test spec with 2 sessions + +starting permutation: b1 b2 r1 r2 w1 w2 c1 c2 +step b1: BEGIN ISOLATION LEVEL SERIALIZABLE; +step b2: BEGIN ISOLATION LEVEL SERIALIZABLE; +step r1: SELECT * FROM test WHERE i IN (5, 7) +i t + +5 apple +7 pear_hot_updated +step r2: SELECT * FROM test WHERE i IN (5, 7) +i t + +5 apple +7 pear_hot_updated +step w1: UPDATE test SET t = 'pear_xact1' WHERE i = 7 +step w2: UPDATE test SET t = 'apple_xact2' WHERE i = 5 +step c1: COMMIT; +step c2: COMMIT; +ERROR: could not serialize access due to read/write dependencies among transactions diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule index 74b50779e25..d6481f6471e 100644 --- a/src/test/isolation/isolation_schedule +++ b/src/test/isolation/isolation_schedule @@ -17,6 +17,7 @@ test: partial-index test: two-ids test: multiple-row-versions test: index-only-scan +test: predicate-lock-hot-tuple test: deadlock-simple test: deadlock-hard test: deadlock-soft diff --git a/src/test/isolation/specs/predicate-lock-hot-tuple.spec b/src/test/isolation/specs/predicate-lock-hot-tuple.spec new file mode 100644 index 00000000000..d16fb60533b --- /dev/null +++ b/src/test/isolation/specs/predicate-lock-hot-tuple.spec @@ -0,0 +1,37 @@ +# Test predicate locks on HOT updated tuples. +# +# This test has two serializable transactions. Both select two rows +# from the table, and then update one of them. +# If these were serialized (run one at a time), the transaction that +# runs later would see one of the rows to be updated. +# +# Any overlap between the transactions must cause a serialization failure. +# We used to have a bug in predicate locking HOT updated tuples, which +# caused the conflict to be missed, if the row was HOT updated. + +setup +{ + CREATE TABLE test (i int PRIMARY KEY, t text); + INSERT INTO test VALUES (5, 'apple'), (7, 'pear'), (11, 'banana'); + -- HOT-update 'pear' row. + UPDATE test SET t = 'pear_hot_updated' WHERE i = 7; +} + +teardown +{ + DROP TABLE test; +} + +session "s1" +step "b1" { BEGIN ISOLATION LEVEL SERIALIZABLE; } +step "r1" { SELECT * FROM test WHERE i IN (5, 7) } +step "w1" { UPDATE test SET t = 'pear_xact1' WHERE i = 7 } +step "c1" { COMMIT; } + +session "s2" +step "b2" { BEGIN ISOLATION LEVEL SERIALIZABLE; } +step "r2" { SELECT * FROM test WHERE i IN (5, 7) } +step "w2" { UPDATE test SET t = 'apple_xact2' WHERE i = 5 } +step "c2" { COMMIT; } + +permutation "b1" "b2" "r1" "r2" "w1" "w2" "c1" "c2" |
