| Bug #71149 | Assertion `((Item_result_field*)item)->result_field' fails in create_tmp_field | ||
|---|---|---|---|
| Submitted: | 16 Dec 2013 9:37 | Modified: | 27 May 2014 8:56 |
| Reporter: | Elena Stepanova | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
| Version: | 5.6.15, 5.7.3-m13 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[16 Dec 2013 9:37]
Elena Stepanova
[16 Dec 2013 10:37]
MySQL Verification Team
Hello Elena, Thank you for the bug report and test case. Verified as described on 5.6.15/5.7.3 debug builds(works fine on release builds). Thanks, Umesh
[16 Dec 2013 15:02]
MySQL Verification Team
looks like a duplicate of my internal
Bug 17607155 - ASSERTION FAILED: ((ITEM_RESULT_FIELD*)ITEM)->RESULT_FIELD
My testcase was:
---
drop table if exists `t`;
create table `t`(`a` int)engine=innodb;
insert `t` values(1);
select '' from `t` group by 1 with rollup having group_concat('');
---
[27 May 2014 8:56]
Erlend Dahl
This has now been fixed in 5.6.20 and 5.7.5.
[6 Aug 2014 17:40]
Laurynas Biveinis
$ bzr log -n0 -r 5950
------------------------------------------------------------
revno: 5950
committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
branch nick: mysql-5.6
timestamp: Wed 2014-05-21 12:46:14 +0530
message:
Bug#11760197:INCORRECT RESULTS WITH COUNT DISTINCT AND BIG_TABLES
Problem:
When big_tables is enabled, COUNT DISTINCT on simple join with
constant equality condition gives wrong result.
Analysis:-
In case of count distinct with sql_big_tables enable, optimizer
saves data in myisam file instead of heap unique tree.
When a constant equality condition is present, it does not
detect duplicate field values when inserting the records into the
temporary table.
Original solution:
While creating temporary table, allow creations of fields for constant
items. When we have distinct query, this will make sure the duplicate
value filtered out when inserting rows in the temporary table.
Side Effects:
Bug#17555462 - SELECT DISTINCT OF VIEW WITH CONSTANT STRING
RETURNS WRONG RESULT
Problem:
In a temporary table if a field is created for a const ref_item,
and if this ref_item is a reference over a constant string and not
on a field results are not as expected.
Analysis:
This is a regression from the patch for Bug#11760197. Post
this bugfix, a field gets created in temporary table
even for const_item's. If the const_item is of type Item_ref,
while creating the temporary field, item->result_field
is made to point to the newly created field.
While the original item would hold the constant's value,
the new field created while changing ref's to use temporary
fields, will not be having the value.
As a result we loose the value when fetching the results.
In similar lines:
Bug #17607155: ASSERTION FAILED: ((ITEM_RESULT_FIELD*)ITEM)->RESULT_FIELD
Bug #17957913: ASSERTION `((ITEM_RESULT_FIELD*)ITEM)->RESULT_FIELD' FAILS
IN CREATE_TMP_FIELD
Problem:
Query having a GROUP BY CLAUSE with ROLLUP modifier and a
GROUP_CONCAT/COUNT(DISTINCT) function with constant expression,
causes an assert.
Analysis:
The GROUP_CONCAT/COUNT(DISTINCT) uses its own temporary table.
When ROLLUP is present it creates the second copy of temporary
table.
This copy receives the same list of arguments that original
group_concat/count(distinct) does which will help to copy
the content of the result_field for the function under
GROUP_CONCAT/COUNT from the first temporary table to the second
temporary table.
In the case, when constant item is present, result_field will carry
null value. After the fix for Bug#11760197, while creating field
for second temporary table as result_field for the constant
expression is not set, it asserts.
Bug#17634335: SELECT DISTINCT...GROUP BY RETURNS WRONG RESULTS
IN SOME CASES
Query creating temporary table to find the distinct value and has
constant value in projected list doesn't give correct result.
Analysis:
After the fix for Bug#11760197 const_items also were created as
part of temporary tables. In the call to remove_duplicates() an
assumption against the same was made which resulted in the above bug.
All the above bugs were side effects of the fix made for Bug#11760197.
Current solution:
Distinct of a constant value will always be the constant value and
count distinct of the same will always be one. Based on this,
a new variable const_distinct is introduced. If enabled, temporary
table is not created and aggregation is also avoided as the result
will always be one.
Works in similar lines to always_null.
