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

Incorrect result when comparing a number with CONNECTION_ID #51840

Closed
Syang111 opened this issue Mar 17, 2024 · 3 comments
Closed

Incorrect result when comparing a number with CONNECTION_ID #51840

Syang111 opened this issue Mar 17, 2024 · 3 comments
Labels
affects-5.4 This bug affects the 5.4.x(LTS) versions. affects-6.1 This bug affects the 6.1.x(LTS) versions. affects-6.5 This bug affects the 6.5.x(LTS) versions. affects-7.1 This bug affects the 7.1.x(LTS) versions. affects-7.5 This bug affects the 7.5.x(LTS) versions. affects-8.1 This bug affects the 8.1.x(LTS) versions. impact/wrong-result severity/major sig/execution SIG execution type/bug The issue is confirmed as a bug.

Comments

@Syang111
Copy link

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

Consider the following statements.

In theory, query1 and query2 should return the same result. However, query1 return nothing while query2 return a CONNECTION_ID 2097158( CONNECTION_ID is different when you reproduce).

CREATE TABLE t0(c0 BIGINT , c1 BLOB(301) , c2 BOOL);
INSERT INTO t0 VALUES (1, 1, 1);


SELECT f1 FROM (SELECT (CONNECTION_ID()) AS f1 FROM t0) AS t WHERE ((f1)>=(-1.487944961E9));  --query1
Empty set (0.00 sec)

SELECT f1 FROM (SELECT (CONNECTION_ID()) AS f1, (((CONNECTION_ID())>=(-1.487944961E9))) IS TRUE AS flag FROM t0) AS t  WHERE flag=1;  --query2
+---------+
| f1      |
+---------+
| 2097158 |
+---------+
1 row in set (0.00 sec)

2. What is your TiDB version? (Required)

v7.6.0, v5.0.1

@Syang111 Syang111 added the type/bug The issue is confirmed as a bug. label Mar 17, 2024
@windtalker
Copy link
Contributor

The root cause is for query 1

SELECT f1 FROM (SELECT (CONNECTION_ID()) AS f1 FROM t0) AS t WHERE ((f1)>=(-1.487944961E9));

The planner tries to convert -1.487944961E9 to uint64(https://github.com/pingcap/tidb/blob/v7.6.0/pkg/expression/builtin_compare.go#L1423), and inside the convert

https://github.com/pingcap/tidb/blob/v7.6.0/pkg/types/convert.go#L169-L183

func ConvertFloatToUint(flags Flags, fval float64, upperBound uint64, tp byte) (uint64, error) {
	val := RoundFloat(fval)
	if val < 0 {
		if !flags.AllowNegativeToUnsigned() {
			return 0, overflow(val, tp)
		}
		return uint64(int64(val)), overflow(val, tp)
	}

	ret, acc := new(big.Float).SetFloat64(val).Uint64()
	if acc == big.Below || ret > upperBound {
		return upperBound, overflow(val, tp)
	}
	return ret, nil
}

It returns uint64(int64(val)), but in https://github.com/pingcap/tidb/blob/v7.6.0/pkg/expression/builtin_compare.go#L1611-L1624

		if isExceptional && arg1.GetType().EvalType() == types.ETInt {
			// Judge it is inf or -inf
			// For int:
			//			inf:  01111111 & 1 == 1
			//		   -inf:  10000000 & 1 == 0
			// For uint:
			//			inf:  11111111 & 1 == 1
			//		   -inf:  00000000 & 1 == 0
			if arg1.Value.GetInt64()&1 == 1 {
				isPositiveInfinite = true
			} else {
				isNegativeInfinite = true
			}
		}

It use arg1.Value.GetInt64()&1 == 1 to check if the return value is +inf or -inf, which is clearly not a right way since uint64(int64(val)) itself is actually a random value based on val

@ti-chi-bot ti-chi-bot added the affects-8.1 This bug affects the 8.1.x(LTS) versions. label Apr 9, 2024
@zimulala zimulala added affects-7.5 This bug affects the 7.5.x(LTS) versions. affects-7.1 This bug affects the 7.1.x(LTS) versions. affects-6.5 This bug affects the 6.5.x(LTS) versions. affects-6.1 This bug affects the 6.1.x(LTS) versions. affects-5.4 This bug affects the 5.4.x(LTS) versions. and removed may-affects-7.1 may-affects-7.5 may-affects-6.5 may-affects-6.1 may-affects-5.4 This bug maybe affects 5.4.x versions. labels Aug 6, 2024
@zimulala
Copy link
Contributor

zimulala commented Aug 6, 2024

Thanks for your report!
We fixed this issue in v8.2.0, and the corresponding PR is #53590.

You can give it a try. I will close this issue for now. If you have any related questions in the future, please feel free to continue providing feedback.

@zimulala zimulala closed this as completed Aug 6, 2024
@XuHuaiyu
Copy link
Contributor

XuHuaiyu commented Aug 8, 2024

dup with #41736

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-5.4 This bug affects the 5.4.x(LTS) versions. affects-6.1 This bug affects the 6.1.x(LTS) versions. affects-6.5 This bug affects the 6.5.x(LTS) versions. affects-7.1 This bug affects the 7.1.x(LTS) versions. affects-7.5 This bug affects the 7.5.x(LTS) versions. affects-8.1 This bug affects the 8.1.x(LTS) versions. impact/wrong-result severity/major sig/execution SIG execution type/bug The issue is confirmed as a bug.
Projects
None yet
Development

No branches or pull requests

6 participants