MDEV-39002: Diagnostics area assertion failure upon CREATE TABLE (ER_CANT_AGGREGATE_2COLLATIONS)#4789
MDEV-39002: Diagnostics area assertion failure upon CREATE TABLE (ER_CANT_AGGREGATE_2COLLATIONS)#4789kjarir wants to merge 1 commit intoMariaDB:10.11from
Conversation
grooverdan
left a comment
There was a problem hiding this comment.
On commit message, its more than just preventing an assertion, its about giving a error message to the user. While the bug report shows a certian behaviour, as you resolve and understand the problem the description of the problem can evolve to something easier to consume, especially for the end user.
I'm slightly surprised this hasn't generated any other test failures (yet?) - https://buildbot.mariadb.org/#/grid?branch=refs%2Fpull%2F4789%2Fhead
mysql-test/main/mdev_39002.test
Outdated
| @@ -0,0 +1,2 @@ | |||
| --error ER_CANT_AGGREGATE_2COLLATIONS | |||
There was a problem hiding this comment.
I'd move this test to part of mysql-test/main/create.test at end, with a :
--echo #
--echo # MDEV-x....
--echo
(the test)
--echo End of 10.11 tests
sql/item_cmpfunc.h
Outdated
| bool fix_length_and_dec(THD *thd) override | ||
| { | ||
| return fix_length_and_dec2_eliminate_null(args + 1); | ||
| if (fix_length_and_dec2_eliminate_null(args + 1)) |
There was a problem hiding this comment.
could be simpler as return fix_length..... but I've no great preference. For multiple expression values like in fix_length_and_dec2 above the verbose forms is needed to be clearer.
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution. This is a preliminary review.
If this fails in 10.6 I'd suggest using 10.6 as a base: it is severe enough I believe.
| `STAGE` tinyint(2) NOT NULL, | ||
| `MAX_STAGE` tinyint(2) NOT NULL, | ||
| `PROGRESS` decimal(7,3) NOT NULL, | ||
| `MEMORY_USED` bigint(7) NOT NULL, |
There was a problem hiding this comment.
why do you have that change? it's causing the buildbot tests to fail.
…REATE TABLE Handle collation mismatch errors during CREATE TABLE by correctly propagating the error status from DEFAULT expression evaluation. When a DEFAULT expression involves a collation mismatch (e.g., IFNULL(a, '') with conflicting charsets), the error is now properly reported to the user instead of triggering a diagnostics area assertion. This fix also addresses test regressions in create.result and follows the mentor's requested test formatting.
|
@grooverdan @gkodinov I've updated the PR by reverting the accidental changes to MEMORY_USED in create.result |
Description
Resolves an assertion failure in Diagnostics_area::set_ok_status that correctly triggered when CREATE TABLE operations involving mismatched collations incorrectly signaled success.
Root Cause:
Methods like Item_func_ifnull::fix_length_and_dec and Item_func_if::fix_length_and_dec were previously ignoring the boolean return value from internal fix_attributes() calls. During functions such as IFNULL encountering collation aggregation failures (e.g., INT paired with a default fallback like swe7_swedish_ci), fix_attributes() properly stored an ER_CANT_AGGREGATE_2COLLATIONS error in the Diagnostics Area. By ignoring fix_attributes()'s failure flag, the parser assumed the step prevailed and eventually hit the assertion while assigning an OK diagnostics status over the stored error.
Solution:
Propagated the boolean return values natively from fix_attributes() calls upwards to parser handlers in sql/item_cmpfunc.h: