mariadb/mysql-test/suite/rpl/t/rpl_not_null_innodb.test

#################################################################################
# This test checks if the replication between "null" fields to either "null"
# fields or "not null" fields works properly. In the first case, the execution
# should work fine. In the second case, it may fail according to the sql_mode
# being used.
#
# The test is devided in three main parts:
#
# 1 - NULL --> NULL (no failures)
# 2 - NULL --> NOT NULL ( sql-mode  = STRICT and failures)
# 3 - NULL --> NOT NULL ( sql-mode != STRICT and no failures)
#
#################################################################################
--source include/master-slave.inc
--source include/have_innodb.inc
--source include/have_binlog_format_row.inc

let $engine=Innodb;
--source extra/rpl_tests/rpl_not_null.test
BUG#43789 different master/slave table defs cause crash: text/varchar null vs not null NOTE: Backporting the patch to next-mr. The replication was generating corrupted data, warning messages on Valgrind and aborting on debug mode while replicating a "null" to "not null" field. Specifically the unpack_row routine, was considering the slave's table definition and trying to retrieve a field value, where there was nothing to be retrieved, ignoring the fact that the value was defined as "null" by the master. To fix the problem, we proceed as follows: 1 - If it is not STRICT sql_mode, implicit default values are used, regardless if it is multi-row or single-row statement. 2 - However, if it is STRICT mode, then a we do what follows: 2.1 If it is a transactional engine, we do a rollback on the first NULL that is to be set into a NOT NULL column and return an error. 2.2 If it is a non-transactional engine and it is the first row to be inserted with multi-row, we also return the error. Otherwise, we proceed with the execution, use implicit default values and print out warning messages. Unfortunately, the current patch cannot mimic the behavior showed by the master for updates on multi-tables and multi-row inserts. This happens because such statements are unfolded in different row events. For instance, considering the following updates and strict mode: (master) create table t1 (a int); create table t2 (a int not null); insert into t1 values (1); insert into t2 values (2); update t1, t2 SET t1.a=10, t2.a=NULL; t1 would have (10) and t2 would have (0) as this would be handled as a multi-row update. On the other hand, if we had the following updates: (master) create table t1 (a int); create table t2 (a int); (slave) create table t1 (a int); create table t2 (a int not null); (master) insert into t1 values (1); insert into t2 values (2); update t1, t2 SET t1.a=10, t2.a=NULL; On the master t1 would have (10) and t2 would have (NULL). On the slave, t1 would have (10) but the update on t1 would fail. 2009-09-29 15:18:44 +01:00			`#################################################################################`
			`# This test checks if the replication between "null" fields to either "null"`
			`# fields or "not null" fields works properly. In the first case, the execution`
			`# should work fine. In the second case, it may fail according to the sql_mode`
			`# being used.`
			`#`
			`# The test is devided in three main parts:`
			`#`
			`# 1 - NULL --> NULL (no failures)`
			`# 2 - NULL --> NOT NULL ( sql-mode = STRICT and failures)`
			`# 3 - NULL --> NOT NULL ( sql-mode != STRICT and no failures)`
			`#`
			`#################################################################################`
			`--source include/master-slave.inc`
			`--source include/have_innodb.inc`
			`--source include/have_binlog_format_row.inc`

			`let $engine=Innodb;`
			`--source extra/rpl_tests/rpl_not_null.test`