database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-06-13 13:01:51 +03:00
Code Activity

BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect

Browse Source 
binlog

Mixing transactional (T) and non-transactional (N) tables on behalf of a
transaction may lead to inconsistencies among masters and slaves in STATEMENT
mode. The problem stems from the fact that although modifications done to
non-transactional tables on behalf of a transaction become immediately visible
to other connections they do not immediately get to the binary log and therefore
consistency is broken. Although there may be issues in mixing T and M tables in
STATEMENT mode, there are safe combinations that clients find useful.

In this bug, we fix the following issue. Mixing N and T tables in multi-level
(e.g. a statement that fires a trigger) or multi-table table statements (e.g.
update t1, t2...) were not handled correctly. In such cases, it was not possible
to distinguish when a T table was updated if the sequence of changes was N and T.
In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect
that both a N and T tables were changed. To circumvent this issue, we check if an
engine is registered in the handler's list and changed something which means that
a T table was modified.

Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or
ROW modes completely safe.
This commit is contained in:
Alfranio Correia
2009-08-27 00:13:03 +01:00
parent 31afccc407
commit dbcfef4cf2
9 changed files with 1642 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
mysql-test/include/commit.inc
View File

@ -725,9 +725,9 @@ call p_verify_status_increment(4, 4, 4, 4);
alter table t3 add column (b int);
call p_verify_status_increment(2, 0, 2, 0);
alter table t3 rename t4;
call p_verify_status_increment(1, 0, 1, 0);
call p_verify_status_increment(2, 2, 2, 2);
rename table t4 to t3;
call p_verify_status_increment(1, 0, 1, 0);
call p_verify_status_increment(2, 2, 2, 2);
truncate table t3;
call p_verify_status_increment(4, 4, 4, 4);
create view v1 as select * from t2;