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 {
| Thread |
|---|
| • bk commit into 4.1 tree (elliot:1.2471) BUG#18283 | Elliot Murphy | 17 Mar |