Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IFNULL produce different result with MySQL on bigint column with unsigned flag #17652

Closed
imtbkcat opened this issue Jun 4, 2020 · 3 comments · Fixed by #21062
Closed

IFNULL produce different result with MySQL on bigint column with unsigned flag #17652

imtbkcat opened this issue Jun 4, 2020 · 3 comments · Fixed by #21062
Assignees
Labels
severity/major sig/execution SIG execution type/bug The issue is confirmed as a bug.

Comments

@imtbkcat
Copy link

imtbkcat commented Jun 4, 2020

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

MySQL [test]> create table t(x bigint unsigned);
Query OK, 0 rows affected (0.006 sec)

MySQL [test]> insert into t values( 9999999703771440633);
Query OK, 1 row affected (0.001 sec)

MySQL [test]> select ifnull(max(x), 0) from t
    -> ;
+----------------------+
| ifnull(max(x), 0)    |
+----------------------+
| -8446744369938110983 |
+----------------------+
1 row in set (0.001 sec)

2. What did you expect to see? (Required)

result should be 9999999703771440633

3. What did you see instead (Required)

-8446744369938110983

4. Affected version (Required)

+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tidb_version()                                                                                                                                                                                                                                                                                                               |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Release Version: v4.0.0-rc.2-35-g8ab455575
Edition: Community
Git Commit Hash: 8ab45557504c922b240ab1aed56e66dc566c71be
Git Branch: release-4.0
UTC Build Time: 2020-06-03 09:30:35
GoVersion: go1.13.9
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

5. Root Cause Analysis

@imtbkcat imtbkcat added the type/bug The issue is confirmed as a bug. label Jun 4, 2020
@zz-jason
Copy link
Member

zz-jason commented Jun 7, 2020

@shuke987 this happens only when the inserted data overflows the max value of signed int64, how about lower the severity to moderate or minor?

TiDB(root@127.0.0.1:test) > create table t(x bigint unsigned);
Query OK, 0 rows affected (0.01 sec)

TiDB(root@127.0.0.1:test) > insert into t values(9999999703771440633);
Query OK, 1 row affected (0.00 sec)

TiDB(root@127.0.0.1:test) > insert into t values(9223372036854775807);
Query OK, 1 row affected (0.00 sec)

TiDB(root@127.0.0.1:test) > select ifnull(max(x), 0) from t;
+----------------------+
| ifnull(max(x), 0)    |
+----------------------+
| -8446744369938110983 |
+----------------------+
1 row in set (0.01 sec)

TiDB(root@127.0.0.1:test) > select ifnull(x, 0) from t;
+----------------------+
| ifnull(x, 0)         |
+----------------------+
| -8446744369938110983 |
|  9223372036854775807 |
+----------------------+
2 rows in set (0.01 sec)

@zz-jason zz-jason added the sig/execution SIG execution label Jun 7, 2020
@ghost ghost added the correctness label Aug 26, 2020
@XuHuaiyu
Copy link
Contributor

Can be closed by
#21062

@ti-srebot
Copy link
Contributor

Please edit this comment or add a new comment to complete the following information

Not a bug

  1. Remove the 'type/bug' label
  2. Add notes to indicate why it is not a bug

Duplicate bug

  1. Add the 'type/duplicate' label
  2. Add the link to the original bug

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

2. Symptom (optional)

3. All Trigger Conditions (optional)

4. Workaround (optional)

5. Affected versions

6. Fixed versions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/major sig/execution SIG execution type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants