-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
max(truncate()) lead to incorrect result #57651
Comments
The root cause is the truncate(0, 309) is NAN now, tmp = 0 * INF, caused NAN, and max(nan, 100) is not stable: if NaN comes first, it is nan; if 100 comes first, it is 100. Not sure if NaN should exist and be taken into consideration. Lines 55 to 68 in 924784a
The reason why query without group by c0 is correct is that its plan is different. It has a topN operator under aggreation, while the topN operator chooses 100 instead of NAN:
|
/severity major |
/remove-label may-affects-5.4 |
/remove-label may-affects-6.1 |
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
result should be 100:
3. What did you see instead (Required)
4. What is your TiDB version? (Required)
topology:
distributed.yaml:
about us
We are the BASS team from the School of Cyber Science and Technology at Beihang University. Our main focus is on system software security, operating systems, and program analysis research, as well as the development of automated program testing frameworks for detecting software defects. Using our self-developed database vulnerability testing tool, we have identified the above-mentioned vulnerabilities in TiDB that may lead to database logic error.
The text was updated successfully, but these errors were encountered: