← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to plugin/innobase/mysql-test/innodb_bug38231.test

  • Committer: Stewart Smith
  • Date: 2010-08-12 16:48:46 UTC
  • mto: This revision was merged to the branch mainline in revision 1707.
  • Revision ID: stewart@flamingspork.com-20100812164846-s9bhy47g60bvqs41
https://launchpad.net/bugs/611379
bug lp:611379 Equivalent queries with Impossible where return different results

The following two equivalent queries return different results in maria 5.2 and 5.3 (and identical results in mysql 5.5.5) :

SELECT SUM( DISTINCT table1 .`pk` ) FROM B table1 STRAIGHT_JOIN ( BB table2 JOIN CC ON table2 .`col_varchar_key` ) ON table2 .`pk` ;

SELECT * FROM ( SELECT SUM( DISTINCT table1 .`pk` ) FROM B table1 STRAIGHT_JOIN ( BB table2 JOIN CC ON table2 .`col_varchar_key` ) ON table2 .`pk` );

MariaDB returns 0 on the second query and NULL on the first, whereas MySQL returns NULL on both. In MariaDB, both EXPLAIN plans agree that "Impossible WHERE noticed after reading const tables"



We have some slightly different output in drizzle:

main.bug_lp611379 [ fail ]
drizzletest: At line 9: query 'explain select * from (select sum(distinct t1.a) from t1,t2 where t1.a=t2.a)
as t' failed: 1048: Column 'sum(distinct t1.a)' cannot be null

but the fix gets us the correct query results, although with slightly different execution plans.



This fix is directly ported from MariaDB.

Show diffs side-by-side

added added

removed removed

Lines of Context:
plugin/innobase/mysql-test/innodb_bug38231.test
1
 
#
2
 
# Bug#38231 Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK
3
 
# http://bugs.mysql.com/38231
4
 
#
5
 
 
6
 
 
7
 
SET storage_engine=InnoDB;
8
 
 
9
 
# we care only that the following SQL commands do not crash the server
10
 
 
11
 
DROP TABLE IF EXISTS bug38231;
12
 
CREATE TABLE bug38231 (a INT);
13
 
 
14
 
 
15
 
SET autocommit=0;
16
 
LOCK TABLE bug38231 WRITE;
17
 
 
18
 
SET autocommit=0;
19
 
LOCK TABLE bug38231 WRITE;
20
 
 
21
 
# When con1 does UNLOCK below this will release either con2 or con3 which are
22
 
# both waiting on LOCK. At the end we must first --reap and UNLOCK the
23
 
# connection that has been released, otherwise it will wait forever. We assume
24
 
# that the released connection will be the first one that has gained the LOCK,
25
 
# thus we force the order here - con2 does LOCK first, then con3. In other
26
 
# words we wait for LOCK from con2 above to be exected before doing LOCK in
27
 
# con3.
28
 
let $wait_condition =
29
 
  SELECT COUNT(*) = 1 FROM information_schema.processlist
30
 
  WHERE info = 'LOCK TABLE bug38231 WRITE';
31
 
# the above enables query log, re-disable it
32
 
 
33
 
SET autocommit=0;
34
 
LOCK TABLE bug38231 WRITE;
35
 
 
36
 
TRUNCATE TABLE bug38231;
37
 
 
38
 
# Wait for TRUNCATE and the other two LOCKs to be executed; without this,
39
 
# sometimes UNLOCK executes before them. We assume there are no other
40
 
# sessions executing at the same time with the same SQL commands.
41
 
let $wait_condition =
42
 
  SELECT COUNT(*) = 1 FROM information_schema.processlist
43
 
  WHERE info = 'TRUNCATE TABLE bug38231';
44
 
let $wait_condition =
45
 
  SELECT COUNT(*) = 2 FROM information_schema.processlist
46
 
  WHERE info = 'LOCK TABLE bug38231 WRITE';
47
 
# the above enables query log, re-disable it
48
 
 
49
 
# this crashes the server if the bug is present
50
 
UNLOCK TABLES;
51
 
 
52
 
# clean up
53
 
 
54
 
UNLOCK TABLES;
55
 
 
56
 
UNLOCK TABLES;
57
 
 
58
 
 
59
 
 
60
 
# test that TRUNCATE works with with row-level locks
61
 
 
62
 
 
63
 
INSERT INTO bug38231 VALUES (1), (10), (300);
64
 
 
65
 
 
66
 
SET autocommit=0;
67
 
SELECT * FROM bug38231 FOR UPDATE;
68
 
 
69
 
TRUNCATE TABLE bug38231;
70
 
 
71
 
COMMIT;
72
 
 
73
 
 
74
 
 
75
 
DROP TABLE bug38231;