From: Date: March 17 2006 10:25am
Subject: bk commit into 4.1 tree (elliot:1.2471) BUG#18283
List-Archive: http://lists.mysql.com/commits/3915
X-Bug: 18283
Message-Id: <20060317092537.871D2204845@localhost.localdomain>

Below is the list of changes that have just been committed into a local
4.1 repository of emurphy. When emurphy does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet
  1.2471 06/03/17 10:25:29 elliot@stripped +1 -0
  BUG#18283 When InnoDB returns error 'lock table full', MySQL can write
  to binlog too much.
  
  When InnoDB has to rollback a transaction because the lock table has
  filled up, it also needs to inform the upper layer that the transaction
  was rolled back so that the cached transaction is not written to the
  binary log.

  sql/ha_innodb.cc
    1.214 06/03/17 10:25:27 elliot@stripped +7 -0
    When InnoDB rolls back a transaction in HA_ERR_LOCK_TABLE_FULL, it
    needs to inform the upper layer to rollback the transaction also.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	elliot
# Host:	xan.(none)
# Root:	/home/emurphy/src/mysql/bk-clean/mysql-4.1

--- 1.213/sql/ha_innodb.cc	2006-01-15 12:50:04 +01:00
+++ 1.214/sql/ha_innodb.cc	2006-03-17 10:25:27 +01:00
@@ -332,6 +332,13 @@
 
     		return(HA_ERR_NO_SAVEPOINT);
   	} else if (error == (int) DB_LOCK_TABLE_FULL) {
+          /* Since we rolled back the whole transaction, we must
+          tell it also to MySQL so that MySQL knows to empty the
+          cached binlog for this transaction */
+
+          if (thd) {
+                  ha_rollback(thd);
+          }
 
     		return(HA_ERR_LOCK_TABLE_FULL);
     	} else {