Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.1.67, 5.2.14, 5.3.12, 5.5.39, 10.0.13
Description
--enable_connect_log
|
|
|
--connect (con1,localhost,root,,)
|
--let $con_id = `SELECT CONNECTION_ID()`
|
|
|
--echo #
|
--echo # This one returns the expected result
|
--echo #
|
SHOW PROCESSLIST;
|
|
|
--connection default
|
eval KILL QUERY $con_id;
|
|
|
--connection con1
|
--echo #
|
--echo # The one after KILL QUERY returns an empty result set (WRONG)
|
--echo #
|
SHOW PROCESSLIST;
|
--echo #
|
--echo # ... and the next one returns the expected result again
|
--echo #
|
SHOW PROCESSLIST;
|
While it is also reproducible on MySQL 5.1-5.6, I'm not filing it upstream, because it's apparently fixed in 5.7 (and hence it has little to no chance to be also fixed in 5.6).
Attachments
Issue Links
- causes
-
-
- Closed
-
Activity
Arguably, KILL QUERY should not affect the next query, only the current one. But should be a subject of a separate bug.
Yes, that's why I filed it as 'Minor' – because the query was not likely to return a meaningful result anyway. The difference is that the error in this situation is annoying, while the empty set is confusing. Confusing is worse.
But for a side note, the behavior with interrupting the next query is not universal. E.g. if we have SHOW MASTER STATUS or SELECT 1, it works. If a table is involved, e.g. SELECT * FROM mysql.user, it doesn't. I don't know the complete criteria for the difference.
The reason for this — KILL QUERY that comes when a connection is idle (is not running any query) will kill the next query. What you see is how a killed SHOW PROCESSLIST looks like. If you'd try a SELECT instead, you'd get
select * from mysql.user;ERROR 70100: Query execution was interruptedI'll fix SHOW PROCESSLIST to do the same.