1
# Tests of various SAVEPOINT functionality
3
# Test for Bug #534806 - SAVEPOINT without active transaction
4
# triggers assert in InnoDB handler
7
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY);
9
UPDATE t1 SET id = 2 WHERE id != 2 LIMIT 0;
14
# Let's test the non-edge case for SAVEPOINTS:
16
# Typical usage pattern of starting a transaction, doing
17
# some work, savepointing, do more work, savepointing, etc
18
# and committing without any rollbacks or savepoint releases.
20
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY);
24
INSERT INTO t1 VALUES (1);
28
INSERT INTO t1 VALUES (2);
32
INSERT INTO t1 VALUES (3);
36
# t1 should now have 1,2,3 in it.
39
# We now test another typical usage pattern, similar to above,
40
# but we issue a ROLLBACK at the end instead of a COMMIT. All
41
# work done in all savepoints should be rolled back.
45
INSERT INTO t1 VALUES (4);
49
INSERT INTO t1 VALUES (5);
53
INSERT INTO t1 VALUES (6);
57
# t1 should still have 1,2,3 in it.
60
# We now test the final typical usage pattern, where we
61
# ROLLBACK work to a specific SAVEPOINT and then COMMIT.
65
INSERT INTO t1 VALUES (4);
69
INSERT INTO t1 VALUES (5);
73
INSERT INTO t1 VALUES (6);
75
ROLLBACK TO SAVEPOINT A;
79
# t1 should have 1,2,3,4 in it.