| Bug #70618 | KILL QUERY kills future queries | ||
|---|---|---|---|
| Submitted: | 14 Oct 2013 19:21 | Modified: | 6 Oct 2014 22:29 |
| Reporter: | Todd Farmer (OCA) | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Connection Handling | Severity: | S3 (Non-critical) |
| Version: | 5.6.14 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[14 Oct 2013 19:24]
Todd Farmer
Tested in 5.6.14 and 5.1.62 - same behavior.
[14 Oct 2013 20:11]
MySQL Verification Team
related: http://bugs.mysql.com/bug.php?id=45679
[6 Oct 2014 22:27]
Todd Farmer
Posted by developer: Fixed in 5.7.1.
[6 Oct 2014 22:29]
Todd Farmer
Duplicate of Bug#45679. fixed in 5.7.1.
Description: Issuing KILL QUERY sets a thread-specific flag which can trigger killing future queries, if the targeted connection is not currently executing queries: session 1> SELECT CONNECTION_ID(); +-----------------+ | CONNECTION_ID() | +-----------------+ | 420932 | +-----------------+ 1 row in set (0.00 sec) session 2> KILL QUERY 420932; Query OK, 0 rows affected (0.00 sec) session 1> SELECT SLEEP(10); +-----------+ | SLEEP(10) | +-----------+ | 1 | +-----------+ 1 row in set (0.00 sec) session 2> KILL QUERY 420932; Query OK, 0 rows affected (0.00 sec) session 1> SELECT user, host FROM mysql.user ORDER BY host, user; ERROR 1317 (70100): Query execution was interrupted The documentation as written today does not seem to leave open the possibility that *future* statements are killed: "KILL QUERY terminates the statement that the connection is *currently* executing, but leaves the connection itself intact." How to repeat: See above, or use following JDBC commands: Statement stmt = conn.createStatement(); stmt.executeQuery("SELECT 1"); stmt.cancel(); stmt.executeQuery("SELECT user, host FROM mysql.user ORDER BY host, user"); Suggested fix: Make thread reset the kill flag at the very start of all command handling, and only terminate commands where KILL QUERY was issued during the execution of said query.