-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Bug Report: Inconsistent Results When Executing SELECT with MAX() Function #15565
Comments
I think there might be an issue with the TryExecute method in go/vt/vtgate/engine/scalar_aggregation.go. To illustrate with my current example, consider a situation where there is only one data entry, but suppose it is split across two shards. In this case, one shard would return null, null, like this
and the other shard would return 1, 5000. , like this
If null, null is in the first row of result.Rows, the final result would be null, 5000. Conversely, if 1, 5000 is in the first row of result.Rows, the final result would be 1, 5000. |
This is not obviously a Vitess bug to me. I say that as the results for the non-aggregated column in the query you ran are not guaranteed in SQL. If you tried to execute the query directly on one of the
When I execute this same query in vtgate (v20-dev):
Are you explicitly modifying MySQL's |
To be more clear, this is not guaranteed in This is the kind of statement that MySQL, many, many years ago, would let you execute w/o any warnings or errors even though the results are not deterministic. The results for that are not deterministic as written, thus them not being deterministic in Vitess is not in and of itself a bug — the same is true in a single stand-alone |
Yes, I changed the sql_mode. Apologies for not mentioning it earlier. I set it globally as follows: SET GLOBAL sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; |
Actually, this SQL comes from here; the original SQL was SELECT empno, MAX(sal) FROM emp HAVING COUNT(*) > 3. I discovered that this SQL could not pass in my test case, so I simplified the SQL and found that it still could not pass. using my current example, MySQL returns a consistent result no matter how many times I execute it. |
If you look at the test executing that query, and the function it uses, you will see that it's confirming in this case that we get the same error when executing it against
And as I showed in my example, they do.
I don't know what this means.
Sure, if the state in that table does not change. Just as in if the rows came back from the shards in the same order every time in vtgate you would get the same results. The point is that the query as you wrote it is non-deterministic so you cannot expect it to be deterministic. I'm going to close this as there's no Vitess bug here that I can see. If you feel it was closed in error, please add a comment with a clear description of what you feel the bug is. |
Overview of the Issue
I've encountered an issue with inconsistent results when executing a query that involves the MAX() aggregate function. The query is as follows:
When I execute this SQL multiple times, the result set of the query is inconsistent, with different empno values being returned for the same MAX(sal) value upon multiple executions.
I expect the query to return a consistent result set each time.
Reproduction Steps
1.Deploy the following vschema:
2.Deploy the following schema:
3.Run
Execute this SQL multiple times and you may see different results.
Binary Version
vtgate version Version: 18.0.3 (Git revision 72528db2b706b7c36bc8236cd765b99b256d247f branch 'HEAD') built on Mon Mar 25 17:21:25 CST 2024 by wangwei@ZBMac-xxxxx using go1.21.8 darwin/arm64
Operating System and Environment details
Log Fragments
No response
The text was updated successfully, but these errors were encountered: