Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.1.67, 5.2.14, 5.3.12, 5.5.39, 10.0.13
-
Component/s: Admin statements
-
Labels:
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).
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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
I'll fix SHOW PROCESSLIST to do the same.