Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
2.5.22, 6.4.3, 22.08.2
-
None
-
MXS-SPRINT-167, MXS-SPRINT-168, MXS-SPRINT-169
Description
If two queries with different canonical query forms (e.g. SELECT user FROM t1 and SELECT host FROM t1) are executed back to back and the first query triggers a latency measurement, the second query can end up being interrupted if it ends up being executed on the server that is measured to be the slower server.
This happens because the KILL QUERY command that is used to interrupt the slower servers is not executed synchronously and just waiting for all the results to complete is not enough: the KILL commands must also complete before new queries should be allowed.
Original description:
The test appears to fail with:
214: 07:45:01 2.1s: TEST_FAILED! Thread 7 failed to SELECT: Query execution was interrupted
|
The query should never get interrupted which means an error leaks to the client that it shouldn't see.