diff options
Diffstat (limited to 'src/test/isolation/specs/predicate-lock-hot-tuple.spec')
-rw-r--r-- | src/test/isolation/specs/predicate-lock-hot-tuple.spec | 37 |
1 files changed, 37 insertions, 0 deletions
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 0000000..5b8aecc --- /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 |