Does MySQLdb rollback on control-C? Maybe not.

John Nagle nagle at
Fri Sep 3 06:22:12 CEST 2010

    I would expect MySQLdb to rollback on a control-C, but it doesn't
seem to have done so.  I have a program which does a thousand or
so INSERT operations in one transaction on an InnoDB table.

    I kill it with a control-C on Windows, and it aborts.  But
it looks like some of the INSERT operations took place.  Here's
the abort, from the middle of an INSERT operation.

Filing index item already in database under another date: 
Traceback (most recent call last):
   File "C:\projects\sitetruth\edgar\", line 93, in 
     cursor.execute(sql, values)                         # do the insert
   File "C:\python26\lib\site-packages\MySQLdb\", line 166, in 
     self.errorhandler(self, exc, value)
   File "C:\python26\lib\site-packages\MySQLdb\", line 35, 
in defaulterrorhandler
     raise errorclass, errorvalue
Terminate batch job (Y/N)? y

    Checking with the manual MySQL client, looking at the table
before and after the run, the table did change when the program ran.
Not good.

    The INSERT looks like this:

	INSERT INTO edgarfilingindex
	(cik, company_name, form_type,
	date_filed, file_name, date_indexed, confidence)
	VALUES (%s,%s,%s,%s,%s,%s,%s)

    SHOW CREATE TABLE returns this:

	CREATE TABLE `edgarfilingindex` (

so it's definitely an InnoDB table.

I have print statements at all commit calls, and there don't seem to
be any unwanted commits happening.  I'm not doing anything that
forces a commit, like RENAME or ALTER or CREATE; it's just
simple INSERT operations.  I'm not doing an explicit START
TRANSACTION, but I shouldn't have to.

I put a SHOW VARIABLES LIKE "autocommit" in the program, and
it comes back with ("autocommit", "OFF").  So that's not the problem.

I even did an explicit START TRANSACTION at the beginning of the
update, and it doesn't help.

Something is broken.

Python 2.6, MySQLdb 1.2.2-py2.6, MySQL 5.1.47-com, Windows 7.

				John Nagle

More information about the Python-list mailing list