← Back to branch summary

~ubuntu-branches/ubuntu/hardy/mysql-dfsg-5.0/hardy-updates

« back to all changes in this revision

Viewing changes to mysql-test/t/ndb_lock.test

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2007-04-02 16:10:53 UTC
  • mfrom: (1.1.9 upstream)
  • Revision ID: james.westby@ubuntu.com-20070402161053-zkil9hjq9k5p1uzv
Tags: 5.0.37-0ubuntu1
https://launchpad.net/bugs/95821
* New upstream bugfix release.
  - Fixes replication failure with auto-increment and on duplicate key
    update, a regression introduced into 5.0.24. (LP: #95821)
* debian/control: Set Ubuntu maintainer.
* debian/rules: Change comments from 'Debian etch' to 'Ubuntu 7.04'.

Show diffs side-by-side

added added

removed removed

Lines of Context:
mysql-test/t/ndb_lock.test
102
102
commit;
103
103
 
104
104
# table scan
105
 
connection con1;
 
105
#
 
106
# Note that there are two distinct execution paths in which we unlock
 
107
# non-matching rows inspected during table scan - one that is used in
 
108
# case of filesort and one that used in rest of cases. Below we cover
 
109
# the latter (Bug #20390 "SELECT FOR UPDATE does not release locks of
 
110
# untouched rows in full table scans").
 
111
connection con1;
 
112
begin;
 
113
# We can't use "order by x" here as it will cause filesort
 
114
--replace_column 1 # 2 # 3 #
 
115
select * from t1 where y = 'one' or y = 'three' for update;
 
116
 
 
117
connection con2;
 
118
begin;
 
119
# Have to check with pk access here since scans take locks on
 
120
# all rows and then release them in chunks
 
121
select * from t1 where x = 2 for update;
 
122
--error 1205
 
123
select * from t1 where x = 1 for update;
 
124
rollback;
 
125
 
 
126
connection con1;
 
127
commit;
 
128
 
 
129
# And now the test for case with filesort
106
130
begin;
107
131
select * from t1 where y = 'one' or y = 'three' order by x for update;
108
 
 
109
132
connection con2;
110
133
begin;
111
 
# Have to check with pk access here since scans take locks on
112
 
# all rows and then release them in chunks
113
 
# Bug #20390 SELECT FOR UPDATE does not release locks of untouched rows in full table scans
114
 
#select * from t1 where x = 2 for update;
 
134
select * from t1 where x = 2 for update;
115
135
--error 1205
116
136
select * from t1 where x = 1 for update;
117
137
rollback;
157
177
# table scan
158
178
connection con1;
159
179
begin;
 
180
# We can't use "order by x" here as it will cause filesort
 
181
--replace_column 1 # 2 # 3 #
 
182
select * from t1 where y = 'one' or y = 'three' lock in share mode;
 
183
 
 
184
connection con2;
 
185
begin;
 
186
select * from t1 where y = 'one' lock in share mode;
 
187
# Have to check with pk access here since scans take locks on
 
188
# all rows and then release them in chunks
 
189
select * from t1 where x = 2 for update;
 
190
--error 1205
 
191
select * from t1 where x = 1 for update;
 
192
rollback;
 
193
 
 
194
connection con1;
 
195
commit;
 
196
 
 
197
# And the same test for case with filesort
 
198
connection con1;
 
199
begin;
160
200
select * from t1 where y = 'one' or y = 'three' order by x lock in share mode;
161
201
 
162
202
connection con2;
163
203
begin;
164
204
select * from t1 where y = 'one' lock in share mode;
165
 
# Have to check with pk access here since scans take locks on
166
 
# all rows and then release them in chunks
167
 
# Bug #20390 SELECT FOR UPDATE does not release locks of untouched rows in full table scans
168
 
#select * from t1 where x = 2 for update;
 
205
select * from t1 where x = 2 for update;
169
206
--error 1205
170
207
select * from t1 where x = 1 for update;
171
208
rollback;