This affects row-based replication for UPDATE/DELETE on tables with no primary key (and no non-NULL unique index).
There was a typo / incorrect merge from the following commit: commit 3abce27e9d45282084aa8d0972ffb6721bac16f5 Author: unknown <[email protected]> Date: Mon Dec 27 22:37:37 2010 +0100 Merge Percona patch row_based_replication_without_primary_key.patch into MariaDB. Instead of referencing the index selected for applying the event, part of the code was referencing the first index (in internal order) in the table. This is code that checks if an index lookup is unique, or if it requires a range scan. This could lead the code to incorrectly do a unique lookup instead of comparing the pre-image against each row in a range scan, thus applying the event to the wrong row and causing replication to diverge. Signed-off-by: Kristian Nielsen <[email protected]> --- mysql-test/suite/rpl/r/rpl_mdev38731.result | 20 ++++++++++++++++++++ mysql-test/suite/rpl/t/rpl_mdev38731.test | 21 +++++++++++++++++++++ sql/log_event_server.cc | 6 +++--- 3 files changed, 44 insertions(+), 3 deletions(-) create mode 100644 mysql-test/suite/rpl/r/rpl_mdev38731.result create mode 100644 mysql-test/suite/rpl/t/rpl_mdev38731.test diff --git a/mysql-test/suite/rpl/r/rpl_mdev38731.result b/mysql-test/suite/rpl/r/rpl_mdev38731.result new file mode 100644 index 00000000000..d099b7af73a --- /dev/null +++ b/mysql-test/suite/rpl/r/rpl_mdev38731.result @@ -0,0 +1,20 @@ +include/master-slave.inc +[connection master] +CREATE TABLE t (a int, b int, c int, d int, KEY (d)) ENGINE=InnoDB; +INSERT INTO t (a,b,d) VALUES +(1,NULL,4),(2,NULL,1),(3,NULL,1), +(4,NULL,1),(5,NULL,1),(6,NULL,1), +(7,0,NULL),(8,NULL,NULL); +ALTER TABLE t ADD UNIQUE (b); +connection slave; +ANALYZE TABLE t; +Table Op Msg_type Msg_text +test.t analyze status Engine-independent statistics collected +test.t analyze status OK +connection master; +UPDATE t SET c = 1; +ALTER TABLE t ADD UNIQUE (a); +connection slave; +connection master; +DROP TABLE t; +include/rpl_end.inc diff --git a/mysql-test/suite/rpl/t/rpl_mdev38731.test b/mysql-test/suite/rpl/t/rpl_mdev38731.test new file mode 100644 index 00000000000..996f4dbce67 --- /dev/null +++ b/mysql-test/suite/rpl/t/rpl_mdev38731.test @@ -0,0 +1,21 @@ +--source include/have_innodb.inc +--source include/have_binlog_format_row.inc +--source include/master-slave.inc + +CREATE TABLE t (a int, b int, c int, d int, KEY (d)) ENGINE=InnoDB; +INSERT INTO t (a,b,d) VALUES + (1,NULL,4),(2,NULL,1),(3,NULL,1), + (4,NULL,1),(5,NULL,1),(6,NULL,1), + (7,0,NULL),(8,NULL,NULL); +ALTER TABLE t ADD UNIQUE (b); +--sync_slave_with_master +ANALYZE TABLE t; +--connection master +UPDATE t SET c = 1; +ALTER TABLE t ADD UNIQUE (a); + +--sync_slave_with_master + +--connection master +DROP TABLE t; +--source include/rpl_end.inc diff --git a/sql/log_event_server.cc b/sql/log_event_server.cc index 3700cb55ac0..2bc64a5b3a1 100644 --- a/sql/log_event_server.cc +++ b/sql/log_event_server.cc @@ -8178,17 +8178,17 @@ int Rows_log_event::find_row(rpl_group_info *rgi) found. I can see no scenario where it would be incorrect to chose the row to change only using a PK or an UNNI. */ - if (table->key_info->flags & HA_NOSAME) + if (m_key_info->flags & HA_NOSAME) { /* Unique does not have non nullable part */ - if (!(table->key_info->flags & (HA_NULL_PART_KEY))) + if (!(m_key_info->flags & (HA_NULL_PART_KEY))) { error= 0; goto end; } else { - KEY *keyinfo= table->key_info; + KEY *keyinfo= m_key_info; /* Unique has nullable part. We need to check if there is any field in the BI image that is null and part of UNNI. -- 2.47.3 _______________________________________________ commits mailing list -- [email protected] To unsubscribe send an email to [email protected]
