-
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.
Mithun C Y authoredISSUE: ------ 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