Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL)
Description
On transaction rollback, we are unnecessarily waiting for redo log to complete. If the server were killed, the transaction would be rolled back just fine. If we are lucky, the changes of the transaction were never written to redo log, and recovery would never even know about the transaction. This is about a minor tweak to the transaction commit code:
diff --git a/storage/innobase/trx/trx0trx.cc b/storage/innobase/trx/trx0trx.cc
|
index 0f735faacfa..f24e44d921a 100644
|
--- a/storage/innobase/trx/trx0trx.cc
|
+++ b/storage/innobase/trx/trx0trx.cc
|
@@ -1347,7 +1347,7 @@ inline void trx_t::commit_in_memory(const mtr_t *mtr)
|
serialize all commits and prevent a group of transactions from
|
gathering. */
|
|
- commit_lsn= mtr->commit_lsn();
|
+ commit_lsn= undo_no ? mtr->commit_lsn() : 0;
|
if (!commit_lsn)
|
/* Nothing to be done. */;
|
else if (flush_log_later) |
This code is also invoked at the end of rollback. The trx_t::undo_no is the number of rows that would remain in the undo log. After a full rollback, that number would always be 0.
A simple benchmark shows the difference:
create table t(id int primary key)engine=innodb; |
delimiter $$
|
create procedure ir(n INT) |
BEGIN
|
DECLARE i INT DEFAULT 0; |
REPEAT
|
START TRANSACTION; INSERT INTO t SET id=0; ROLLBACK; |
SET i:=i+1; |
UNTIL i>n END REPEAT; |
END$$ |
delimiter ;
|
call ir(10000);
|
On my system, with innodb_flush_log_at_trx_commit=1, the test before the patch takes 7.6 seconds. With the patch, it is only 2.3 seconds.
Attachments
Issue Links
- relates to
-
-
- Closed
-