Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
12.0.1
-
None
-
Not for Release Notes
Description
Reproduction Steps
CREATE TABLE v0 (v1 DECIMAL(10,2), v2 INT); |
 |
UPDATE v0 SET v1 = v1 IN ( |
SELECT v1 FROM ( |
SELECT v1 FROM v0 AS v3 |
WHERE ( -1, v1, 33 ) < ( 255, 0, v1 ) |
AND v1 = ( SELECT 0 ^ 2147483647 / 56 - 0 + -1 + -128 AS v4 FROM v0 ) |
) AS v2 |
WHERE ( 127, v1, -1 ) < ( 75, 47, v1 ) |
)
|
WHERE v1 > 14 OR v1 > 99 AND v1; |
Key Point: The query involves row comparison with DECIMAL field and subquery that may return NULL.
Stack Trace
#0 __pthread_kill_implementation
|
#1 raise
|
#2 abort
|
#3 __assert_fail_base.cold
|
#4 __assert_fail
|
#5 Field_new_decimal::get_equal_const_item (sql/field.cc:3945)
|
#6 Item_field::propagate_equal_fields (sql/item.cc:6737)
|
#7 Item_direct_view_ref::propagate_equal_fields (sql/item.cc:9773)
|
#8 Item::propagate_equal_fields_and_change_item_tree (sql/item.cc:7835)
|
#9 Item_args::propagate_equal_fields (sql/item_func.cc:598)
|
#10 Item_row::propagate_equal_fields (sql/item_row.h:131)
|
#11 Item::propagate_equal_fields_and_change_item_tree (sql/item.cc:7835)
|
#12 Item_args::propagate_equal_fields (sql/item_func.cc:598)
|
#13 Item_bool_rowready_func2::propagate_equal_fields
|
#14 Item_func::build_equal_items (sql/sql_select.cc:18567)
|
#15 Item_cond_and::build_equal_items (sql/sql_select.cc:18422)
|
#16 build_equal_items (sql/sql_select.cc:18669)
|
#17 optimize_cond (sql/sql_select.cc:20536)
|
#18 JOIN::optimize_inner (sql/sql_select.cc:2428)
|
...
|
From AI Root Cause Analysis
The issue occurs in Field_new_decimal::get_equal_const_item() when processing equality propagation for DECIMAL
fields:
// sql/field.cc:3932-3963 |
Item *Field_new_decimal::get_equal_const_item(THD *thd, const Context &ctx, |
Item *const_item)
|
{
|
...
|
if (const_item->field_type() != MYSQL_TYPE_NEWDECIMAL || |
const_item->decimal_scale() != decimals())
|
{
|
VDec val(const_item);
|
if (val.is_null()) |
{
|
DBUG_ASSERT(0); // <-- Assertion fails here |
return const_item; |
}
|
...
|
}
|
...
|
}
|
Problem Flow:
1. During query optimization, propagate_equal_fields is called to identify equal fields
2. For DECIMAL field v1, get_equal_const_item() is called
3. When the constant item is NULL (from subquery result or row comparison)
4. VDec val(const_item) succeeds but val.is_null() returns true
5. The code hits DBUG_ASSERT(0) instead of handling NULL gracefully
Possible Fix
The assertion DBUG_ASSERT(0) should be removed and the code should simply return const_item when the value is
NULL, as NULL values do not need precision conversion:
VDec val(const_item);
|
if (val.is_null()) |
{
|
return const_item; // Simply return, no conversion needed for NULL |
}
|
mysql> CREATE TABLE v0 (v1 DECIMAL(10,2), v2 INT);
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql> UPDATE v0 SET v1 = v1 IN (
-> SELECT v1 FROM (
-> SELECT v1 FROM v0 AS v3
-> WHERE ( -1, v1, 33 ) < ( 255, 0, v1 )
-> AND v1 = ( SELECT 0 ^ 2147483647 / 56 - 0 + -1 + -128 AS v4 FROM v0 )
-> ) AS v2
-> WHERE ( 127, v1, -1 ) < ( 75, 47, v1 )
-> )
-> WHERE v1 > 14 OR v1 > 99 AND v1;
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
ERROR 2003 (HY000): Can't connect to MySQL server on '21.91.3.238:3307' (111)
ERROR:
Can't connect to the server
mysql>
Attachments
Issue Links
- duplicates
-
-
- Confirmed
-