mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2026-04-29 11:45:32 +02:00
Code Issues Projects Releases Packages Wiki Activity

BUG#860580: Sporadic crash / valgrind warning in register_field_in_read_map() with semijoin

Browse source 
The problem: in an uncorrelated subquery, JOIN execution code may make 
irreversible cleanups after it has been executed (because the subquery 
won't be executed again). In particular, JTBM nests and their injected 
IN-equalities will be invalidated (the materialized table will be dropped
and TABLE structure freed).
Solution: don't walk into Item_subselect if represents an uncorrelated 
subselect that has already been executed. The idea is that the subselect
will not be executed again (calling Item_subselect_xxx::val_int() will fetch
the cached value), so it should not matter what is inside the subselect.
This commit is contained in:
Sergey Petrunya 2011-10-06 01:11:08 +04:00
commit 0200ee7003
1 changed files with 14 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

14
sql/item_subselect.cc
View file

@ -514,6 +514,20 @@ void Item_subselect::recalc_used_tables(st_select_lex *new_parent,
bool Item_subselect::walk(Item_processor processor, bool walk_subquery,
uchar *argument)
{
if (!(unit->uncacheable & ~UNCACHEABLE_DEPENDENT) && engine->is_executed() &&
!unit->describe)
{
/*
The subquery has already been executed (for real, it wasn't EXPLAIN's
fake execution) so it should not matter what it has inside.
The actual reason for not walking inside is that parts of the subquery
(e.g. JTBM join nests and their IN-equality conditions may have been
invalidated by irreversible cleanups (those happen after an uncorrelated
subquery has been executed).
*/
return FALSE;
}
if (walk_subquery)
{