Skip to content
  • Mithun C Y's avatar
    f289aeee
    Bug #17055185 : WRONG RESULTS WHEN RUNNING A SELECT THAT INCLUDES A HAVING BASED ON A FUNCTION. · f289aeee
    Mithun C Y authored
    ISSUE:
    ------
    In end_write and end_write_group, Item_refs in having
    conditions should refer to tmp_table->record[0]. But
    join->ref_ptrs is not set to tmp_table->ref_array
    because of this Item_refs in having is referring to Items
    before tmp table. This lead to re-evaluation expressions
    in having. Non-deterministic functions like rand() on
    re-evaluation produces different results. If having refers
    to one such expression in select list and it re-evaluate
    them instead of referring to the saved results through
    tmp_table->ref_array, can result in inconsistent results.
    A similar issue in end_send where we need to refer to
    grouping ref_array. Example: In loose index scan where
    having refers to non-deterministic expression can result
    in inconsistent results.
    
    Solution:
    ---------
    If there is no select distinct, convert having condition
    to temp table conditions. With this Item_ref in having
    will be converted to Item_field of temp field. Since
    temp table already stores the result of group items, new
    Item_fields will refer to these stored results now.
    
    NOTE:
    -----
    1. We cannot set the join->ref_ptrs to tmp table ref_array
    as in end_send_group, because this have impact on PREPARE
    EXEC statements, reason is in JOIN::optimize we still do
    resolution under the flag "first_optimization", here we try
    to save select_lex->prep_where for next execution. Setting
    ref_ptrs can make outer ref in where clause to point to
    temp table items, so prep_where will point to some temp
    table items, which will be freed after execution, for next
    execution of same statement prep_where points to freed
    items, then de-referencing same!!!.
    This issue is solved with WL7082 in 5.7
    2. If distinct is there I cannot move the having after
    applying distinct reason is if having items of having
    condition are not part of distinct then distinct key
    may remove rows witch satisfy having and keep which
    do not satisfy having. Thus me may loose some valid
    rows before applying having.
    3. If plan is loose index scan we do not fix it in 5.6
    because to fix this in end_send we need to set
    join->ref_ptrs to items3. As in point 1 doing any such
    things in 5.6 will lead to crash for PS. Already we have
    similar issue for end_send_group. so avoiding it.
    f289aeee
    Bug #17055185 : WRONG RESULTS WHEN RUNNING A SELECT THAT INCLUDES A HAVING BASED ON A FUNCTION.
    Mithun C Y authored
    ISSUE:
    ------
    In end_write and end_write_group, Item_refs in having
    conditions should refer to tmp_table->record[0]. But
    join->ref_ptrs is not set to tmp_table->ref_array
    because of this Item_refs in having is referring to Items
    before tmp table. This lead to re-evaluation expressions
    in having. Non-deterministic functions like rand() on
    re-evaluation produces different results. If having refers
    to one such expression in select list and it re-evaluate
    them instead of referring to the saved results through
    tmp_table->ref_array, can result in inconsistent results.
    A similar issue in end_send where we need to refer to
    grouping ref_array. Example: In loose index scan where
    having refers to non-deterministic expression can result
    in inconsistent results.
    
    Solution:
    ---------
    If there is no select distinct, convert having condition
    to temp table conditions. With this Item_ref in having
    will be converted to Item_field of temp field. Since
    temp table already stores the result of group items, new
    Item_fields will refer to these stored results now.
    
    NOTE:
    -----
    1. We cannot set the join->ref_ptrs to tmp table ref_array
    as in end_send_group, because this have impact on PREPARE
    EXEC statements, reason is in JOIN::optimize we still do
    resolution under the flag "first_optimization", here we try
    to save select_lex->prep_where for next execution. Setting
    ref_ptrs can make outer ref in where clause to point to
    temp table items, so prep_where will point to some temp
    table items, which will be freed after execution, for next
    execution of same statement prep_where points to freed
    items, then de-referencing same!!!.
    This issue is solved with WL7082 in 5.7
    2. If distinct is there I cannot move the having after
    applying distinct reason is if having items of having
    condition are not part of distinct then distinct key
    may remove rows witch satisfy having and keep which
    do not satisfy having. Thus me may loose some valid
    rows before applying having.
    3. If plan is loose index scan we do not fix it in 5.6
    because to fix this in end_send we need to set
    join->ref_ptrs to items3. As in point 1 doing any such
    things in 5.6 will lead to crash for PS. Already we have
    similar issue for end_send_group. so avoiding it.
Loading