The fix for bug lp:944706 (MDEV-193) makes the fix by MySQL unnecessary.
The reason is that the patch for lp:944706 pre-optimizes all constant
subqueries. Therefore, the subquery in test case is optimized in the
thread MEM_ROOT, and all its related data structures are there. Thus
deleting works fine. Item_func_like::select_optimize only executes the
subquery, which is fine too.
Unlike MariaDB, MySQL still has lazy optimization. As a result, when
Item_func_like::select_optimize executes the subquery, it also optimizes
the subquery just before execution. Naturally, this happens in the wrong
MEM_ROOT which is deleted after we exit the range optimizer. When the
recursive JOIN cleanup tries to delete optimizer-related class members
of the subquery, this memory is already gone, hence we get a crash.
So with respect to this specific bug, there is nothing to fix.
I will add an is_expensive() guard + the test case to the tree with the lp:944706 fix.
I will not add MySQL's patch, as it is not needed.
The fix for bug lp:944706 (MDEV-193) makes the fix by MySQL unnecessary. like::select_ optimize only executes the
The reason is that the patch for lp:944706 pre-optimizes all constant
subqueries. Therefore, the subquery in test case is optimized in the
thread MEM_ROOT, and all its related data structures are there. Thus
deleting works fine. Item_func_
subquery, which is fine too.
Unlike MariaDB, MySQL still has lazy optimization. As a result, when like::select_ optimize executes the subquery, it also optimizes
Item_func_
the subquery just before execution. Naturally, this happens in the wrong
MEM_ROOT which is deleted after we exit the range optimizer. When the
recursive JOIN cleanup tries to delete optimizer-related class members
of the subquery, this memory is already gone, hence we get a crash.
So with respect to this specific bug, there is nothing to fix.
I will add an is_expensive() guard + the test case to the tree with the lp:944706 fix.
I will not add MySQL's patch, as it is not needed.