MySQL Bugs: #29949: killing a statement can give back wrong error to client

Bug #29949	killing a statement can give back wrong error to client
Submitted:	21 Jul 2007 18:45	Modified:	1 Aug 2007 20:26
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: General	Severity:	S2 (Serious)
Version:	5.0.46	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
When issuing a KILL <id> to an insert statement, the client gets back a wrong error message, sometimes.

Usually, we have the expected errors:

query failed 'INSERT INTO `t1`(`b`) VALUES (REPEAT('a',2))' : 2013 (Lost connection to MySQL server during query)

query failed 'INSERT INTO `t1`(`b`) VALUES (REPEAT('a',2))' : 1053 (Server shutdown in progress)

However, we sometimes see this (wrong error):

query failed 'INSERT INTO `t1`(`b`) VALUES (REPEAT('a',2))' : 1054 (Unknown column 'b' in 'field list')

It's funny, because `t1` is defined as:

CREATE TEMPORARY TABLE IF NOT EXISTS `t1`(`a` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,`b` CHAR(255))ENGINE=INNODB;

How to repeat:
just run a bunch of inserts, and issue KILL <id> until you see this error. Be quick!  I'll upload some code to repeat this later.

Suggested fix:
.

Another manifestation.  KILL <id> where id is busy preparing a SELECT statement can fail like this:

thread [010] mysql_stmt_prepare failed: Unknown column 'a' in 'where clause' (1054)

This happens with:

SELECT * FROM `t1` WHERE `a` > 1

On closer examination, it seems there was a real table `t1`, in the test database.  Sometimes the temporary table `t1` failed to be created, and then the real `t1` without the column was accessed!  I had overlooked it at the time :)