Bug#54453: Failing assertion: trx->active_trans when renaming a

           table with active trx

Essentially, the problem is that InnoDB does a implicit commit
when a cursor (table handler) is unlocked/closed, creating
a dissonance between the transaction state within the server
layer and the storage engine layer. Theoretically, a statement
transaction can encompass several table instances in a similar
manner to a multiple statement transaction, hence it does not
make sense to limit a statement transaction to the lifetime of
the table instances (cursors) used within it.

Since this particular instance of the problem is only triggerable
on 5.1 and is masked on 5.5 due 2PC being skipped (assertion is in
the prepare phase of a 2PC), the solution (which is less risky) is
to explicitly end the transaction before the cached table is unlock
on rename table.

The patch is to be null merged into trunk.

mysql-test/include/commit.inc:
  Fix counters, the binlog engine does not get involved anymore.
mysql-test/suite/innodb_plugin/r/innodb_bug54453.result:
  Add test case result for Bug#54453
mysql-test/suite/innodb_plugin/t/innodb_bug54453.test:
  Add test case for Bug#54453
sql/sql_table.cc:
  End transaction as otherwise InnoDB will end it behind our backs.

1 files changed, 8 insertions, 0 deletions

diff --git a/sql/sql_table.cc b/sql/sql_table.cc
index 50045ec6d90..47b91fcca0e 100644
--- a/sql/sql_table.cc
+++ b/sql/sql_table.cc
@@ -6848,6 +6848,14 @@ view_err:
     if (!error && (new_name != table_name || new_db != db))
     {
       thd_proc_info(thd, "rename");
+
+      /*
+        Workaround InnoDB ending the transaction when the table instance
+        is unlocked/closed (close_cached_table below), otherwise the trx
+        state will differ between the server and storage engine layers.
+      */
+      ha_autocommit_or_rollback(thd, 0);
+
       /*
         Then do a 'simple' rename of the table. First we need to close all
         instances of 'source' table.