The problem was that THD::killed was reset after a command was
read from the socket, but before it was actually handled. That lead
to a race: if another KILL statement was issued for this connection
in the middle of reading from the socket and processing a command,
THD::killed state would be cleaned.

The fix is to move this cleanup into net_send_error() function.

A sample test case exists in binlog_killed.test:
  - connection 1: start a new transaction on table t1;
  - connection 2: send query to the server (w/o waiting for the
    result) to update data in table t1 -- this query will be blocked
    since there is unfinished transaction;
  - connection 1: kill query in connection 2 and finish the transaction;
  - connection 2: get result of the previous query -- it should be
    the "query-killed" error.

This test however contains race condition, which can not be fixed
with the current protocol: there is no way to guarantee, that the
server will receive and start processing the query in connection 2
(which is intended to get blocked) before the KILL command (sent in
the connection 1) will arrive. In other words, there is no way to
ensure that the following sequence will not happen:

  - connection 1: start a new transaction on table t1;
  - connection 1: kill query in connection 2 and finish the transaction;
  - connection 2: send query to the server (w/o waiting for the
    result) to update data in table t1 -- this query will be blocked
    since there is unfinished transaction;
  - connection 2: get result of the previous query -- the query will
    succeed.

So, there is no test case for this bug, since it's impossible
to write a reliable test case under the current circumstances.


sql/protocol.cc:
  Move thd->killed cleanup from dispatch_command() to net_send_error().
sql/sql_parse.cc:
  Move thd->killed cleanup from dispatch_command() to net_send_error().