1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
#
# Test multi update with different join methods
#
CREATE TABLE bug38999_1 (a int not null primary key, b int not null, key (b)) engine=innodb;
CREATE TABLE bug38999_2 (a int not null primary key, b int not null, key (b)) engine=innodb;
INSERT INTO bug38999_1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(10,10),(11,11),(12,12);
INSERT INTO bug38999_2 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9);
# Full join, without key
update bug38999_1,bug38999_2 set bug38999_1.a=bug38999_1.a+100;
--sorted_result
select * from bug38999_1;
# unique key
update bug38999_1,bug38999_2 set bug38999_1.a=bug38999_1.a+100 where bug38999_1.a=101;
--sorted_result
select * from bug38999_1;
# ref key
update bug38999_1,bug38999_2 set bug38999_1.b=bug38999_1.b+10 where bug38999_1.b=2;
--sorted_result
select * from bug38999_1;
# Run ANALYZE in order to increase the likelihood of getting the same
# query plan on every run of the next update statement.
# Note: With different query plans, the next update statement can produce
# different results that are still valid.
--disable_query_log
--disable_result_log
ANALYZE TABLE bug38999_1,bug38999_2;
--enable_result_log
--enable_query_log
# Range key (in bug38999_1)
# To ensure stable test case: The use of force index (b) is added in order
# to ensure that this index is used. If this index is not used, the order
# of the assigments can change and a different but still valid result can be
# produced from this statement.
update bug38999_1 force index (b) straight_join bug38999_2
set bug38999_1.b=bug38999_1.b+2,
bug38999_2.b=bug38999_1.b+10
where bug38999_1.b between 3 and 5 and bug38999_1.a=bug38999_2.a+100;
--sorted_result
select * from bug38999_1;
# It is unspecified whether the assignment of bug38999_2.b sees the
# modification of bug38999_1.b on the same row. The hypergraph optimizer
# chooses a different plan (not using range scan on bug38999_1.b, as that
# prevents immediate update) and does the assignments in a different
# order.
--skip_if_hypergraph
--sorted_result
select * from bug38999_2;
drop table bug38999_1,bug38999_2;
--echo #
--echo # Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--echo #
CREATE TABLE t1(f1 INT) ENGINE=INNODB;
INSERT INTO t1 VALUES(1);
--error ER_OPERAND_COLUMNS
UPDATE (SELECT ((SELECT 1 FROM t1), 1) FROM t1 WHERE (SELECT 1 FROM t1)) x, (SELECT 1) AS d SET d.f1 = 1;
DROP TABLE t1;
|
