diff options
author | Igor Babaev <igor@askmonty.org> | 2016-11-21 10:33:06 -0800 |
---|---|---|
committer | Igor Babaev <igor@askmonty.org> | 2016-11-21 10:33:39 -0800 |
commit | 665045f985787d77318a17ccddd67ec3ff92f7bc (patch) | |
tree | 9c5680ffaae3c4a6d35abac1418c0f99105e9eb1 /sql/item_subselect.cc | |
parent | 022aeda4c01a1be47abdfe90a59df2dc0b72828d (diff) | |
download | mariadb-git-665045f985787d77318a17ccddd67ec3ff92f7bc.tar.gz |
Fixed bug mdev-11081.
The idea of this fix was taken from the patch by Roy Lyseng
for mysql-5.6 bug iBug#14740889: "Wrong result for aggregate
functions when executing query through cursor".
Here's Roy's comment for his patch:
"
The problem was that a grouped query did not behave properly when
executed using a cursor. On further inspection, the query used one
intermediate temporary table for the grouping.
Then, Select_materialize::send_result_set_metadata created a temporary
table for storing the query result. Notice that get_unit_column_types()
is used to retrieve column meta-data for the query. The items contained
in this list are later modified so that their result_field points to
the row buffer of the materialized temporary table for the cursor.
But prior to this, these result_field objects have been prepared for
use in the grouping operation, by JOIN::make_tmp_tables_info(), hence
the grouping operation operates on wrong column buffers.
The problem is solved by using the list JOIN::fields when copying data
to the materialized table. This list is set by JOIN::make_tmp_tables_info()
and points to the columns of the last intermediate temporary table of
the executed query. For a UNION, it points to the temporary table
that is the result of the UNION query.
Notice that we have to assign a value to ::fields early in JOIN::optimize()
in case the optimization shortcuts due to a const plan detection.
A more optimal solution might be to avoid creating the final temporary
table when the query result is already stored in a temporary table.
"
The patch does not contain a test case, but the description of the
problem corresponds exactly what could be observed in the test
case for mdev-11081.
Diffstat (limited to 'sql/item_subselect.cc')
-rw-r--r-- | sql/item_subselect.cc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc index 21c633333f1..e90efbd82be 100644 --- a/sql/item_subselect.cc +++ b/sql/item_subselect.cc @@ -4572,7 +4572,7 @@ subselect_hash_sj_engine::get_strategy_using_schema() return COMPLETE_MATCH; else { - List_iterator<Item> inner_col_it(*item_in->unit->get_unit_column_types()); + List_iterator<Item> inner_col_it(*item_in->unit->get_column_types(false)); Item *outer_col, *inner_col; for (uint i= 0; i < item_in->left_expr->cols(); i++) |