mirror of
https://github.com/MariaDB/server.git
synced 2025-02-01 03:21:53 +01:00
b0035c76d4
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. |
||
|---|---|---|
| .. | ||
| binlog | ||
| bugs | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| ibmdb2i | ||
| im | ||
| innodb | ||
| innodb_plugin | ||
| jp | ||
| large_tests | ||
| manual | ||
| ndb | ||
| ndb_team | ||
| parts | ||
| rpl | ||
| rpl_ndb | ||
| stress | ||
| sys_vars | ||