• unknown's avatar
    Test case for bug lp:1001117, MySQL BUG#12330344 · 4fa89b5f
    unknown authored
    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.
    4fa89b5f
partition.test 64.1 KB