Commit f9b43c25 authored by Varun Gupta's avatar Varun Gupta

MDEV-16751: Server crashes in st_join_table::cleanup or...

MDEV-16751: Server crashes in st_join_table::cleanup or TABLE_LIST::is_with_table_recursive_reference
            with join_cache_level>2

During muliple equality propagation for a query in which we have an IN subquery, the items in the select list of the
subquery may not be part of the multiple equality because there might be another occurence of the same field in the
where clause of the subquery.
So we keyuse_is_valid_for_access_in_chosen_plan function which expects the items in the select list of the subquery to
be same to the ones in the multiple equality (through these multiple equalities we create keyuse array).
The solution would be that we expect the same field not the same Item because when we have SEMI JOIN MATERIALIZATION SCAN,
we use copy back technique to copies back the materialised table fields to the original fields of the base tables.
parent d567f161
......@@ -2360,6 +2360,41 @@ ec70316637232000158bbfc8bcbe5d60
ebb4620037332000158bbfc8bcbe5d89
DROP TABLE t1,t2,t3;
set optimizer_switch=@save_optimizer_switch;
#
# MDEV-16751: Server crashes in st_join_table::cleanup or
# TABLE_LIST::is_with_table_recursive_reference with join_cache_level>2
#
set @save_join_cache_level= @@join_cache_level;
set join_cache_level=4;
CREATE TABLE t1 ( id int NOT NULL);
INSERT INTO t1 VALUES (11),(12),(13),(14),(15),(16),(17),(18),(19);
CREATE TABLE t2 (i1 int NOT NULL, i2 int NOT NULL) ;
INSERT INTO t2 VALUES (11,11),(12,12),(13,13);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 hash_ALL NULL #hash#$hj 4 test.t2.i1 9 Using where; Using join buffer (flat, BNLH join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
set @@join_cache_level= @save_join_cache_level;
alter table t1 add key(id);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 ref id id 4 test.t2.i1 2 Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
drop table t1,t2;
# End of 5.5 tests
set @subselect_mat_test_optimizer_switch_value=null;
set @@optimizer_switch='materialization=on,in_to_exists=off,semijoin=off';
......
......@@ -2400,4 +2400,39 @@ ec70316637232000158bbfc8bcbe5d60
ebb4620037332000158bbfc8bcbe5d89
DROP TABLE t1,t2,t3;
set optimizer_switch=@save_optimizer_switch;
#
# MDEV-16751: Server crashes in st_join_table::cleanup or
# TABLE_LIST::is_with_table_recursive_reference with join_cache_level>2
#
set @save_join_cache_level= @@join_cache_level;
set join_cache_level=4;
CREATE TABLE t1 ( id int NOT NULL);
INSERT INTO t1 VALUES (11),(12),(13),(14),(15),(16),(17),(18),(19);
CREATE TABLE t2 (i1 int NOT NULL, i2 int NOT NULL) ;
INSERT INTO t2 VALUES (11,11),(12,12),(13,13);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 hash_ALL NULL #hash#$hj 4 test.t2.i1 9 Using where; Using join buffer (flat, BNLH join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
set @@join_cache_level= @save_join_cache_level;
alter table t1 add key(id);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 ref id id 4 test.t2.i1 2 Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
drop table t1,t2;
# End of 5.5 tests
......@@ -2151,4 +2151,29 @@ eval $q;
DROP TABLE t1,t2,t3;
set optimizer_switch=@save_optimizer_switch;
--echo #
--echo # MDEV-16751: Server crashes in st_join_table::cleanup or
--echo # TABLE_LIST::is_with_table_recursive_reference with join_cache_level>2
--echo #
set @save_join_cache_level= @@join_cache_level;
set join_cache_level=4;
CREATE TABLE t1 ( id int NOT NULL);
INSERT INTO t1 VALUES (11),(12),(13),(14),(15),(16),(17),(18),(19);
CREATE TABLE t2 (i1 int NOT NULL, i2 int NOT NULL) ;
INSERT INTO t2 VALUES (11,11),(12,12),(13,13);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
set @@join_cache_level= @save_join_cache_level;
alter table t1 add key(id);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
drop table t1,t2;
--echo # End of 5.5 tests
......@@ -815,6 +815,9 @@ int check_and_do_in_subquery_rewrites(JOIN *join)
details)
* require that compared columns have exactly the same type. This is
a temporary measure to avoid BUG#36752-type problems.
JOIN_TAB::keyuse_is_valid_for_access_in_chosen_plan expects that for Semi Join Materialization
Scan all the items in the select list of the IN Subquery are of the type Item::FIELD_ITEM.
*/
static
......
......@@ -7445,8 +7445,13 @@ bool JOIN_TAB::keyuse_is_valid_for_access_in_chosen_plan(JOIN *join,
st_select_lex *sjm_sel= emb_sj_nest->sj_subq_pred->unit->first_select();
for (uint i= 0; i < sjm_sel->item_list.elements; i++)
{
if (sjm_sel->ref_pointer_array[i] == keyuse->val)
return true;
DBUG_ASSERT(sjm_sel->ref_pointer_array[i]->type() == Item::FIELD_ITEM);
if (keyuse->val->type() == Item::FIELD_ITEM)
{
Field *field = ((Item_field*)sjm_sel->ref_pointer_array[i])->field;
if (field->eq(((Item_field*)keyuse->val)->field))
return true;
}
}
return false;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment