Skip to content

Commit 2bf6f2c

Browse files
committed
MDEV-26077 Assertion err != DB_DUPLICATE_KEY or unexpected ER_TABLE_EXISTS_ERROR
This is a backport of 161e4bf. trans_rollback_to_savepoint(): Only release metadata locks (MDL) if the storage engines agree, after the changes were already rolled back. Ever since commit 3792693 and mysql/mysql-server@55ceedb we used to cheat here and always release MDL if the binlog is disabled. MDL are supposed to prevent race conditions between DML and DDL also when no replication is in use. MDL are supposed to be a superset of InnoDB table locks: InnoDB table lock may only exist if the thread also holds MDL on the table name. In the included test case, ROLLBACK TO SAVEPOINT would wrongly release the MDL on both tables and let ALTER TABLE proceed, even though the DML transaction is actually holding locks on the table. Until commit 1bd681c (MDEV-25506) in MariaDB 10.6, InnoDB would often work around the locking violation in a blatantly non-ACID way: If locks exist on a table that is being dropped (in this case, actually a partition of a table that is being rebuilt by ALTER TABLE), InnoDB could move the table (or partition) into a queue, to be dropped after the locks and references had been released. If the lock is not released and the original copy of the table not dropped quickly enough, a name conflict could occur on a subsequent ALTER TABLE. The scenario of commit 3792693 is unaffected by this fix, because mysqldump would use non-locking reads, and the transaction would not be holding any InnoDB locks during the execution of ROLLBACK TO SAVEPOINT. MVCC reads inside InnoDB are only covered by MDL and page latches, not by any table or record locks. FIXME: It would be nice if storage engines were specifically asked which MDL can be released, instead of only offering a choice between all or nothing. InnoDB should be able to release any locks for tables that are no longer in trx_t::mod_tables, except if another transaction had converted some implicit record locks to explicit ones, before the ROLLBACK TO SAVEPOINT had been completed. Reviewed by: Sergei Golubchik
1 parent 5a2b625 commit 2bf6f2c

File tree

3 files changed

+80
-27
lines changed

3 files changed

+80
-27
lines changed
Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
#
2+
# MDEV-26077 Assertion failure err != DB_DUPLICATE_KEY
3+
# or unexpected ER_TABLE_EXISTS_ERROR
4+
#
5+
CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
6+
CREATE TABLE t2 (pk INT PRIMARY KEY) ENGINE=InnoDB;
7+
connect con1,localhost,root,,test;
8+
START TRANSACTION;
9+
INSERT INTO t2 (pk) VALUES (1);
10+
SAVEPOINT sp;
11+
INSERT INTO t1 (pk) VALUES (1);
12+
ROLLBACK TO SAVEPOINT sp;
13+
connection default;
14+
SET lock_wait_timeout=0;
15+
Warnings:
16+
Warning 1292 Truncated incorrect lock_wait_timeout value: '0'
17+
SET innodb_lock_wait_timeout=0;
18+
Warnings:
19+
Warning 1292 Truncated incorrect innodb_lock_wait_timeout value: '0'
20+
ALTER TABLE t1 PARTITION BY HASH(pk);
21+
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
22+
SHOW CREATE TABLE t1;
23+
Table Create Table
24+
t1 CREATE TABLE `t1` (
25+
`pk` int(11) NOT NULL,
26+
PRIMARY KEY (`pk`)
27+
) ENGINE=InnoDB DEFAULT CHARSET=latin1
28+
connection con1;
29+
COMMIT;
30+
connection default;
31+
ALTER TABLE t2 PARTITION BY HASH(pk);
32+
disconnect con1;
33+
connection default;
34+
DROP TABLE t1, t2;
35+
# End of 10.2 tests
Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
--source include/have_innodb.inc
2+
--source include/have_partition.inc
3+
4+
--echo #
5+
--echo # MDEV-26077 Assertion failure err != DB_DUPLICATE_KEY
6+
--echo # or unexpected ER_TABLE_EXISTS_ERROR
7+
--echo #
8+
9+
CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
10+
CREATE TABLE t2 (pk INT PRIMARY KEY) ENGINE=InnoDB;
11+
12+
--connect (con1,localhost,root,,test)
13+
14+
START TRANSACTION;
15+
INSERT INTO t2 (pk) VALUES (1);
16+
SAVEPOINT sp;
17+
INSERT INTO t1 (pk) VALUES (1);
18+
ROLLBACK TO SAVEPOINT sp;
19+
20+
--connection default
21+
SET lock_wait_timeout=0;
22+
SET innodb_lock_wait_timeout=0;
23+
--error ER_LOCK_WAIT_TIMEOUT
24+
ALTER TABLE t1 PARTITION BY HASH(pk);
25+
26+
SHOW CREATE TABLE t1;
27+
--connection con1
28+
COMMIT;
29+
--connection default
30+
ALTER TABLE t2 PARTITION BY HASH(pk);
31+
# Cleanup
32+
--disconnect con1
33+
--connection default
34+
DROP TABLE t1, t2;
35+
36+
--echo # End of 10.2 tests

sql/transaction.cc

Lines changed: 9 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,5 @@
11
/* Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
2+
Copyright (c) 2009, 2021, MariaDB Corporation.
23
34
This program is free software; you can redistribute it and/or modify
45
it under the terms of the GNU General Public License as published by
@@ -696,32 +697,6 @@ bool trans_rollback_to_savepoint(THD *thd, LEX_STRING name)
696697
if (WSREP_ON)
697698
wsrep_register_hton(thd, thd->in_multi_stmt_transaction_mode());
698699

699-
/**
700-
Checking whether it is safe to release metadata locks acquired after
701-
savepoint, if rollback to savepoint is successful.
702-
703-
Whether it is safe to release MDL after rollback to savepoint depends
704-
on storage engines participating in transaction:
705-
706-
- InnoDB doesn't release any row-locks on rollback to savepoint so it
707-
is probably a bad idea to release MDL as well.
708-
- Binary log implementation in some cases (e.g when non-transactional
709-
tables involved) may choose not to remove events added after savepoint
710-
from transactional cache, but instead will write them to binary
711-
log accompanied with ROLLBACK TO SAVEPOINT statement. Since the real
712-
write happens at the end of transaction releasing MDL on tables
713-
mentioned in these events (i.e. acquired after savepoint and before
714-
rollback ot it) can break replication, as concurrent DROP TABLES
715-
statements will be able to drop these tables before events will get
716-
into binary log,
717-
718-
For backward-compatibility reasons we always release MDL if binary
719-
logging is off.
720-
*/
721-
bool mdl_can_safely_rollback_to_savepoint=
722-
(!(mysql_bin_log.is_open() && thd->variables.sql_log_bin) ||
723-
ha_rollback_to_savepoint_can_release_mdl(thd));
724-
725700
if (ha_rollback_to_savepoint(thd, sv))
726701
res= TRUE;
727702
else if (((thd->variables.option_bits & OPTION_KEEP_LOG) ||
@@ -733,7 +708,14 @@ bool trans_rollback_to_savepoint(THD *thd, LEX_STRING name)
733708

734709
thd->transaction.savepoints= sv;
735710

736-
if (!res && mdl_can_safely_rollback_to_savepoint)
711+
if (res)
712+
/* An error occurred during rollback; we cannot release any MDL */;
713+
else if (thd->variables.sql_log_bin && mysql_bin_log.is_open())
714+
/* In some cases (such as with non-transactional tables) we may
715+
choose to preserve events that were added after the SAVEPOINT,
716+
delimiting them by SAVEPOINT and ROLLBACK TO SAVEPOINT statements.
717+
Prematurely releasing MDL on such objects would break replication. */;
718+
else if (ha_rollback_to_savepoint_can_release_mdl(thd))
737719
thd->mdl_context.rollback_to_savepoint(sv->mdl_savepoint);
738720

739721
DBUG_RETURN(MY_TEST(res));

0 commit comments

Comments
 (0)