Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.25
-
None
-
None
Description
rpl_mdev382 tests, besides other things, binlogging of implicitly emptied MEMORY tables.
The assert that fires is here:
3275 bool Prepared_statement::prepare(const char *packet, uint packet_len)
|
3276 {
|
...
|
3361 error= check_prepared_statement(this);
|
...
|
3372 /* No need to commit statement transaction, it's not started. */
|
3373 DBUG_ASSERT(thd->transaction.stmt.is_empty());
|
...
|
Indeed, the "statement transaction" is not supposed to be started. But the check_prepared_statement call above opens all tables, and the "implicitly emptied" MEMORY table too, which triggers binlog write, which starts the transaction.
Besides an assert it might be wrong on other layers too. What if the transaction is rolled back? What if the statement fails and is rolled back? DELETE must still be in binlog, strictly speaking it's not part of the transaction.
Attachments
Issue Links
- duplicates
-
MDEV-493 Assertion thd->transaction.stmt.is_empty() in prepared statement when MEMORY table implicitly dropped after server restart
- Closed