Test case for bug lp:1001117, MySQL BUG#12330344
Analysis: The problem in the original MySQL bug is that the range optimizer performs its analysis in a separate MEM_ROOT object that is freed after the range optimzier is done. During range analysis get_mm_tree calls Item_func_like::select_optimize, which in turn evaluates its right argument. In the test case the right argument is a subquery. In MySQL, subqueries are optimized lazyly, thus the call to val_str triggers optimization for the subquery. All objects needed by the subquery plan end up in the temporary MEM_ROOT used by the range optimizer. When execution ends, the JOIN::cleanup process tries to cleanup objects of the subquery plan, but all these objects are gone with the temporary MEM_ROOT. The solution for MySQL is to switch the mem_root. In MariaDB with the patch for bug lp:944706, all constant subqueries that may be used by the optimization process are preoptimized. Therefore Item_func_like::select_optimize only triggers subquery execution, and the above problem is not present. The patch however adds a test whether the evaluated right argument of the LIKE predicate is expensive. This is consistent with our approach not to evaluate expensive expressions during optimization.
Showing
Please register or sign in to comment