MySQL Bugs: #50218: CTRL-C behavior faulty for mysql client on Windows

Bug #50218	CTRL-C behavior faulty for mysql client on Windows
Submitted:	11 Jan 2010 0:25	Modified:	11 Jan 2010 4:22
Reporter:	Roel Van de Paar	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S3 (Non-critical)
Version:	5.1.42	OS:	Microsoft Windows
Assigned to:		CPU Architecture:	Any
Tags:	regression

Description:
Pressing CTRL-C during a long running query results in various behaviors. Here's one example which looks incorrect and is very repeatable (ctrl-c was only pressed during the first and third query):

---
mysql> select * from daytime;
+---------------------+
| DATE_TIME           |
+---------------------+
| 2010-01-11 10:54:22 |
| 2010-01-11 10:55:52 |
[...]
| 2010-01-11 10:54:22 |
| 2010-01-11 10:55:52 |
| 201Ctrl-C -- sending "KILL QUERY 7" to server ...     /* CTRL-C pressed */
0-01Ctrl-C -- query aborted.
-11 10:55:53 |
+---------------------+
425984 rows in set (1.09 sec)

mysql> select * from daytime;
ERROR 1317 (70100): Query execution was interrupted
mysql> select * from daytime;
+---------------------+
| DATE_TIME           |
+---------------------+
| 2010-01-11 10:54:22 |
| 2010-01-11 10:55:52 |
[...]
| 2010-01-11 10:55:54 |
| 2010-01-11 10:55:54 |
| 2010-01-11^C                       /* CTRL-C pressed */
C:\mysql5142\bin>
---

However, if 'SELECT 1' is issued, the result different:

-----
mysql> select * from daytime;
[...]
| 2010-01-11 10:55:56 |
| 2010-01-11 10:55:56 |
| 201Ctrl-C -- sending "KILL QUERY 3" to server ...
0Ctrl-C -- query aborted.
-01-11 10:55:56 |
+---------------------+
425984 rows in set (1.17 sec)

mysql> select 1;
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)

mysql> select * from daytime;
+---------------------+
| DATE_TIME           |
+---------------------+
| 2010-01-11 10:54:22 |
| 2010-01-11 10:55:52 |
[...]
| 2010-01-11 10:55:56 |
| 2010-01-11 10:55:56 |
^C
C:\mysql5142\bin>           /* Still exited incorrectly, but ERROR 1317 never showed */
-----

How to repeat:
As per the above

Suggested fix:
#1 Client should not have reported 'ERROR 1317 (70100): Query execution was interrupted' after query 2 (in example 1)
#2 Client should not have exited after CTRL-C was pressed again during query 3 (in both examples)

Regression of bug #17926 (also see bug #1989)

'SIGINT is handled in funny ways on windows, which could lead to problems when Control-C was pressed in the client during a long-running query.  Now Control-C during a query aborts that query (by sending KILL to the server on a second connexion), while Control-C outside of a running query terminates the client.'

Observed behavior is different, as per the above.

Verifying as D2 (Dysfunction)

For completeness, see bug #26892, bug #26243, bug #29497

If I understand the issue correctly, it has nothing to do with the client. client sends kill and server in some circumstances kills the _future_ query, bnot the current query. Have seen this in Connector/Net too