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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
|
-- source include/have_ndb.inc
-- source include/not_embedded.inc
connect (con1,localhost,root,,);
connect (con2,localhost,root,,);
--disable_warnings
DROP TABLE IF EXISTS t1,t2,t3,t4,t5,t6,t7;
--enable_warnings
#
# Transaction lock test to show that the NDB
# table handler is working properly with
# transaction locks
#
#
# Testing of scan isolation
#
connection con1;
create table t1 (x integer not null primary key, y varchar(32)) engine = ndb;
insert into t1 values (1,'one'), (2,'two');
select * from t1 order by x;
connection con2;
select * from t1 order by x;
connection con1;
start transaction;
insert into t1 values (3,'three');
select * from t1 order by x;
connection con2;
start transaction;
select * from t1 order by x;
connection con1;
commit;
connection con2;
select * from t1 order by x;
commit;
drop table t1;
###
# Bug#6020
create table t1 (pk integer not null primary key, u int not null, o int not null,
unique(u), key(o)) engine = ndb;
insert into t1 values (1,1,1), (2,2,2), (3,3,3), (4,4,4), (5,5,5);
lock tables t1 write;
delete from t1 where pk = 1;
unlock tables;
select * from t1 order by pk;
insert into t1 values (1,1,1);
lock tables t1 write;
delete from t1 where u = 1;
unlock tables;
select * from t1 order by pk;
insert into t1 values (1,1,1);
lock tables t1 write;
delete from t1 where o = 1;
unlock tables;
select * from t1 order by pk;
insert into t1 values (1,1,1);
drop table t1;
# Lock for update
create table t1 (x integer not null primary key, y varchar(32), z integer, key(z)) engine = ndb;
insert into t1 values (1,'one',1);
# PK access
connection con1;
begin;
select * from t1 where x = 1 for update;
connection con2;
begin;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
rollback;
insert into t1 values (2,'two',2),(3,"three",3);
begin;
select * from t1 where x = 1 for update;
connection con2;
--error 1205
select * from t1 where x = 1 for update;
select * from t1 where x = 2 for update;
rollback;
connection con1;
commit;
# table scan
#
# Note that there are two distinct execution paths in which we unlock
# non-matching rows inspected during table scan - one that is used in
# case of filesort and one that used in rest of cases. Below we cover
# the latter (Bug #20390 "SELECT FOR UPDATE does not release locks of
# untouched rows in full table scans").
connection con1;
begin;
# We can't use "order by x" here as it will cause filesort
--replace_column 1 # 2 # 3 #
select * from t1 where y = 'one' or y = 'three' for update;
connection con2;
begin;
# Have to check with pk access here since scans take locks on
# all rows and then release them in chunks
select * from t1 where x = 2 for update;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
commit;
# And now the test for case with filesort
begin;
select * from t1 where y = 'one' or y = 'three' order by x for update;
connection con2;
begin;
select * from t1 where x = 2 for update;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
commit;
# index scan
connection con1;
begin;
select * from t1 where z > 1 and z < 3 for update;
connection con2;
begin;
# Have to check with pk access here since scans take locks on
# all rows and then release them in chunks
select * from t1 where x = 1 for update;
--error 1205
select * from t1 where x = 2 for update;
rollback;
connection con1;
commit;
# share locking
# PK access
connection con1;
begin;
select * from t1 where x = 1 lock in share mode;
connection con2;
begin;
select * from t1 where x = 1 lock in share mode;
select * from t1 where x = 2 for update;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
commit;
# table scan
connection con1;
begin;
# We can't use "order by x" here as it will cause filesort
--replace_column 1 # 2 # 3 #
select * from t1 where y = 'one' or y = 'three' lock in share mode;
connection con2;
begin;
select * from t1 where y = 'one' lock in share mode;
# Have to check with pk access here since scans take locks on
# all rows and then release them in chunks
select * from t1 where x = 2 for update;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
commit;
# And the same test for case with filesort
connection con1;
begin;
select * from t1 where y = 'one' or y = 'three' order by x lock in share mode;
connection con2;
begin;
select * from t1 where y = 'one' lock in share mode;
select * from t1 where x = 2 for update;
--error 1205
select * from t1 where x = 1 for update;
rollback;
connection con1;
commit;
# index scan
connection con1;
begin;
select * from t1 where z > 1 and z < 3 lock in share mode;
connection con2;
begin;
select * from t1 where z = 1 lock in share mode;
# Have to check with pk access here since scans take locks on
# all rows and then release them in chunks
select * from t1 where x = 1 for update;
--error 1205
select * from t1 where x = 2 for update;
rollback;
connection con1;
commit;
drop table t1;
# End of 4.1 tests
#
# Bug #17812 Previous lock table for write causes "stray" lock
# although table is recreated
#
# this creating, locking, and dropping causes a subsequent hang
# on the delete below waiting for table t2 the locking in the
# "other" connection is relevant, as without it there is no problem
#
connection con1;
create table t3 (id2 int) engine=ndb;
connection con2;
lock tables t3 write;
unlock tables;
connection con1;
drop table t3;
connection con1;
create table t2 (id int, j int) engine=ndb;
insert into t2 values (2, 2);
create table t3 (id int) engine=ndb;
connection con2;
lock tables t3 read;
connection con1;
# here we get a hang before bugfix although we shouldn't
delete t2 from t2, t3 where t2.id = t3.id;
connection con2;
unlock tables;
connection con1;
drop table t2, t3;
|
