| Bug #18283 | When InnoDB returns error 'lock table full', MySQL can write to binlog too much | ||
|---|---|---|---|
| Submitted: | 16 Mar 2006 15:48 | Modified: | 22 Mar 2006 17:36 |
| Reporter: | Heikki Tuuri | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
| Version: | 4.1, 5.0, 5.1 | OS: | Any (All) |
| Assigned to: | Elliot Murphy | CPU Architecture: | Any |
[17 Mar 2006 9:25]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/3915
[22 Mar 2006 11:40]
Elliot Murphy
Fix has been pushed for 5.1.9 and 5.0.20
[22 Mar 2006 17:36]
Mike Hillyer
Noted in changelog:
<listitem>
<para>
If InnoDB encountered a
<literal>HA_ERR_LOCK_TABLE_FULL</literal> error and
rolled-back a transaction, the transaction was still written
to the binary log. (Bug #18283)
</para>
</listitem>
Description: InnoDB rolls back the whole transaction in HA_ERR_LOCK_TABLE_FULL, but forgot to tell that to MySQL. Since InnoDB stores locks in very small space, it is extremely rare that a user encounters this bug. I am assigning this to Elliot Murphy because the patch has to be applied to ha_innodb.cc. How to repeat: Run a VERY big SELECT ... FOR UPDATE with a 8 MB buffer pool. Suggested fix: This should be fixed in 4.1, 5.0, 5.1: --- ha_innodb.cc 2006-03-16 17:42:57.305108104 +0200 +++ ha_innodb_fixed.cc 2006-03-16 17:45:37.743717728 +0200 @@ -513,6 +513,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 {