Re: signal handling in mysql cli
- Date: Tue, 2 Dec 2014 18:31:53 +0100 (CET)
- From: Johan De Meersman <vegivamp@xxxxxxxxx>
- Subject: Re: signal handling in mysql cli
----- Original Message -----
> From: "wharms" <wharms@xxxxxx>
> Subject: signal handling in mysql cli
> when i use CTRL-C to break a query that works fine in interactive mode.
> but when i use the noninteractive mode
> i looks like that but "show full processlist;" shows otherwise and that is true
This may sound silly, but you're basically saying that you can't interact with it while in non-interactive mode...
My understanding may be wrong, but this is how it works in my mind:
* when in the client, the client intercepts the ctrl-c and interprets it as "kill this query on the server".
* when in non-interactive mode, the client is not actually reading your keypresses. Thus, the ctrl-c gets intercepted by the *shell*, which does exactly what you ask by killing the MySQL client process.
Now, if the mysql client does not explicitly intercept kill signals - which, honestly, most programs have no reason to - that means it doesn't even get a chance to send the "cancel that query" order, it just dies.
A lot of debate could be put in on wether or not the client needs to intercept and send a cancel, but personally I'm leaning towards "no, it doesn't" - if you don't have a transaction open, or don't even have a transactional engine (which used to be default!) cancelling would leave your database in an inconsistent state. Much better, then, to allow whatever query you sent to continue, on the off chance that it's something that it does not damage, or only does things that you can reverse afterwards. If you really want to kill that query, you always have the option of logging into the server and shooting it yourself.
Unhappiness is discouraged and will be corrected with kitten pictures.
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql