You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

360 lines
10 KiB

BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
15 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
15 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
15 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
15 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
15 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam 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.
16 years ago
  1. #################################################################################
  2. # This test checks if the replication between "null" fields to either "null"
  3. # fields or "not null" fields works properly. In the first case, the execution
  4. # should work fine. In the second case, it may fail according to the sql_mode
  5. # being used.
  6. #
  7. # The test is devided in three main parts:
  8. #
  9. # 1 - NULL --> NULL (no failures)
  10. # 2 - NULL --> NOT NULL ( sql-mode = STRICT and failures)
  11. # 3 - NULL --> NOT NULL ( sql-mode != STRICT and no failures)
  12. #
  13. #################################################################################
  14. connection master;
  15. SET SQL_LOG_BIN= 0;
  16. eval CREATE TABLE t1(`a` INT, `b` DATE DEFAULT NULL,
  17. `c` INT DEFAULT NULL,
  18. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  19. eval CREATE TABLE t2(`a` INT, `b` DATE DEFAULT NULL,
  20. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  21. eval CREATE TABLE t3(`a` INT, `b` DATE DEFAULT NULL,
  22. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  23. eval CREATE TABLE t4(`a` INT, `b` DATE DEFAULT NULL,
  24. `c` INT DEFAULT NULL,
  25. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  26. SET SQL_LOG_BIN= 1;
  27. connection slave;
  28. eval CREATE TABLE t1(`a` INT, `b` DATE DEFAULT NULL,
  29. `c` INT DEFAULT NULL,
  30. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  31. eval CREATE TABLE t2(`a` INT, `b` DATE DEFAULT NULL,
  32. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  33. eval CREATE TABLE t3(`a` INT, `b` DATE DEFAULT '0000-00-00',
  34. `c` INT DEFAULT 500,
  35. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  36. eval CREATE TABLE t4(`a` INT, `b` DATE DEFAULT '0000-00-00',
  37. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  38. --echo ************* EXECUTION WITH INSERTS *************
  39. connection master;
  40. INSERT INTO t1(a,b,c) VALUES (1, null, 1);
  41. INSERT INTO t1(a,b,c) VALUES (2,'1111-11-11', 2);
  42. INSERT INTO t1(a,b) VALUES (3, null);
  43. INSERT INTO t1(a,c) VALUES (4, 4);
  44. INSERT INTO t1(a) VALUES (5);
  45. INSERT INTO t2(a,b) VALUES (1, null);
  46. INSERT INTO t2(a,b) VALUES (2,'1111-11-11');
  47. INSERT INTO t2(a) VALUES (3);
  48. INSERT INTO t3(a,b) VALUES (1, null);
  49. INSERT INTO t3(a,b) VALUES (2,'1111-11-11');
  50. INSERT INTO t3(a) VALUES (3);
  51. INSERT INTO t4(a,b,c) VALUES (1, null, 1);
  52. INSERT INTO t4(a,b,c) VALUES (2,'1111-11-11', 2);
  53. INSERT INTO t4(a,b) VALUES (3, null);
  54. INSERT INTO t4(a,c) VALUES (4, 4);
  55. INSERT INTO t4(a) VALUES (5);
  56. --echo ************* SHOWING THE RESULT SETS WITH INSERTS *************
  57. sync_slave_with_master;
  58. --echo TABLES t1 and t2 must be equal otherwise an error will be thrown.
  59. let $diff_tables= master:t1, slave:t1;
  60. source include/diff_tables.inc;
  61. let $diff_tables= master:t2, slave:t2;
  62. source include/diff_tables.inc;
  63. --echo TABLES t2 and t3 must be different.
  64. connection master;
  65. SELECT * FROM t3 ORDER BY a;
  66. connection slave;
  67. SELECT * FROM t3 ORDER BY a;
  68. connection master;
  69. SELECT * FROM t4 ORDER BY a;
  70. connection slave;
  71. SELECT * FROM t4 ORDER BY a;
  72. --echo ************* EXECUTION WITH UPDATES and REPLACES *************
  73. connection master;
  74. DELETE FROM t1;
  75. INSERT INTO t1(a,b,c) VALUES (1,'1111-11-11', 1);
  76. REPLACE INTO t1(a,b,c) VALUES (2,'1111-11-11', 2);
  77. UPDATE t1 set b= NULL, c= 300 where a= 1;
  78. REPLACE INTO t1(a,b,c) VALUES (2, NULL, 300);
  79. --echo ************* SHOWING THE RESULT SETS WITH UPDATES and REPLACES *************
  80. sync_slave_with_master;
  81. --echo TABLES t1 and t2 must be equal otherwise an error will be thrown.
  82. let $diff_tables= master:t1, slave:t1;
  83. source include/diff_tables.inc;
  84. --echo ************* CLEANING *************
  85. connection master;
  86. DROP TABLE t1;
  87. DROP TABLE t2;
  88. DROP TABLE t3;
  89. DROP TABLE t4;
  90. sync_slave_with_master;
  91. connection master;
  92. SET SQL_LOG_BIN= 0;
  93. eval CREATE TABLE t1 (`a` INT, `b` BIT DEFAULT NULL, `c` BIT DEFAULT NULL,
  94. PRIMARY KEY (`a`)) ENGINE= $engine;
  95. SET SQL_LOG_BIN= 1;
  96. connection slave;
  97. eval CREATE TABLE t1 (`a` INT, `b` BIT DEFAULT b'01', `c` BIT DEFAULT NULL,
  98. PRIMARY KEY (`a`)) ENGINE= $engine;
  99. --echo ************* EXECUTION WITH INSERTS *************
  100. connection master;
  101. INSERT INTO t1(a,b,c) VALUES (1, null, b'01');
  102. INSERT INTO t1(a,b,c) VALUES (2,b'00', b'01');
  103. INSERT INTO t1(a,b) VALUES (3, null);
  104. INSERT INTO t1(a,c) VALUES (4, b'01');
  105. INSERT INTO t1(a) VALUES (5);
  106. --echo ************* SHOWING THE RESULT SETS WITH INSERTS *************
  107. --echo TABLES t1 and t2 must be different.
  108. sync_slave_with_master;
  109. connection master;
  110. SELECT a,b+0,c+0 FROM t1 ORDER BY a;
  111. connection slave;
  112. SELECT a,b+0,c+0 FROM t1 ORDER BY a;
  113. --echo ************* EXECUTION WITH UPDATES and REPLACES *************
  114. connection master;
  115. DELETE FROM t1;
  116. INSERT INTO t1(a,b,c) VALUES (1,b'00', b'01');
  117. REPLACE INTO t1(a,b,c) VALUES (2,b'00',b'01');
  118. UPDATE t1 set b= NULL, c= b'00' where a= 1;
  119. REPLACE INTO t1(a,b,c) VALUES (2, NULL, b'00');
  120. --echo ************* SHOWING THE RESULT SETS WITH UPDATES and REPLACES *************
  121. --echo TABLES t1 and t2 must be equal otherwise an error will be thrown.
  122. sync_slave_with_master;
  123. let $diff_tables= master:t1, slave:t1;
  124. source include/diff_tables.inc;
  125. connection master;
  126. DROP TABLE t1;
  127. sync_slave_with_master;
  128. --echo ################################################################################
  129. --echo # NULL ---> NOT NULL (STRICT MODE)
  130. --echo # UNCOMMENT THIS AFTER FIXING BUG#43992
  131. --echo ################################################################################
  132. #connection slave;
  133. #SET GLOBAL sql_mode="TRADITIONAL";
  134. #
  135. #STOP SLAVE;
  136. #--source include/wait_for_slave_to_stop.inc
  137. #START SLAVE;
  138. #--source include/wait_for_slave_to_start.inc
  139. #
  140. #let $y=0;
  141. #while ($y < 6)
  142. #{
  143. # connection master;
  144. #
  145. # SET SQL_LOG_BIN= 0;
  146. # eval CREATE TABLE t1(`a` INT NOT NULL, `b` INT,
  147. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  148. # eval CREATE TABLE t2(`a` INT NOT NULL, `b` INT,
  149. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  150. # eval CREATE TABLE t3(`a` INT NOT NULL, `b` INT,
  151. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  152. # SET SQL_LOG_BIN= 1;
  153. #
  154. # connection slave;
  155. #
  156. # eval CREATE TABLE t1(`a` INT NOT NULL, `b` INT NOT NULL,
  157. # `c` INT NOT NULL,
  158. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  159. # eval CREATE TABLE t2(`a` INT NOT NULL, `b` INT NOT NULL,
  160. # `c` INT,
  161. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  162. # eval CREATE TABLE t3(`a` INT NOT NULL, `b` INT NOT NULL,
  163. # `c` INT DEFAULT 500,
  164. # PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  165. #
  166. # if ($y==0)
  167. # {
  168. # --echo ************* EXECUTION WITH INSERTS *************
  169. # connection master;
  170. # INSERT INTO t1(a) VALUES (1);
  171. # }
  172. #
  173. # if ($y==1)
  174. # {
  175. # --echo ************* EXECUTION WITH INSERTS *************
  176. # connection master;
  177. # INSERT INTO t1(a, b) VALUES (1, NULL);
  178. # }
  179. #
  180. # if ($y==2)
  181. # {
  182. # --echo ************* EXECUTION WITH UPDATES *************
  183. # connection master;
  184. # INSERT INTO t3(a, b) VALUES (1, 1);
  185. # INSERT INTO t3(a, b) VALUES (2, 1);
  186. # UPDATE t3 SET b = NULL where a= 1;
  187. # }
  188. #
  189. # if ($y==3)
  190. # {
  191. # --echo ************* EXECUTION WITH INSERTS/REPLACES *************
  192. # connection master;
  193. # REPLACE INTO t3(a, b) VALUES (1, null);
  194. # }
  195. #
  196. # if ($y==4)
  197. # {
  198. # --echo ************* EXECUTION WITH UPDATES/REPLACES *************
  199. # connection master;
  200. # INSERT INTO t3(a, b) VALUES (1, 1);
  201. # REPLACE INTO t3(a, b) VALUES (1, null);
  202. # }
  203. #
  204. # if ($y==5)
  205. # {
  206. # --echo ************* EXECUTION WITH MULTI-ROW INSERTS *************
  207. # connection master;
  208. #
  209. # SET SQL_LOG_BIN= 0;
  210. # INSERT INTO t2(a, b) VALUES (1, 1);
  211. # INSERT INTO t2(a, b) VALUES (2, 1);
  212. # INSERT INTO t2(a, b) VALUES (3, null);
  213. # INSERT INTO t2(a, b) VALUES (4, 1);
  214. # INSERT INTO t2(a, b) VALUES (5, 1);
  215. # SET SQL_LOG_BIN= 1;
  216. #
  217. # INSERT INTO t2 SELECT a + 10, b from t2;
  218. # --echo The statement below is just executed to stop processing
  219. # INSERT INTO t1(a) VALUES (1);
  220. # }
  221. #
  222. # --echo ************* SHOWING THE RESULT SETS *************
  223. # connection slave;
  224. # --source include/wait_for_slave_sql_to_stop.inc
  225. # connection master;
  226. # SELECT * FROM t1 ORDER BY a;
  227. # connection slave;
  228. # SELECT * FROM t1 ORDER BY a;
  229. # connection master;
  230. # SELECT * FROM t2 ORDER BY a;
  231. # connection slave;
  232. # SELECT * FROM t2 ORDER BY a;
  233. # connection master;
  234. # SELECT * FROM t3 ORDER BY a;
  235. # connection slave;
  236. # SELECT * FROM t3 ORDER BY a;
  237. # --source include/rpl_reset.inc
  238. #
  239. # connection master;
  240. #
  241. # DROP TABLE t1;
  242. # DROP TABLE t2;
  243. # DROP TABLE t3;
  244. #
  245. # sync_slave_with_master;
  246. #
  247. # inc $y;
  248. #}
  249. #connection slave;
  250. #SET GLOBAL sql_mode="";
  251. #
  252. #STOP SLAVE;
  253. #source include/wait_for_slave_to_stop.inc;
  254. #START SLAVE;
  255. #--source include/wait_for_slave_to_start.inc
  256. --echo ################################################################################
  257. --echo # NULL ---> NOT NULL (NON-STRICT MODE)
  258. --echo ################################################################################
  259. connection master;
  260. SET SQL_LOG_BIN= 0;
  261. eval CREATE TABLE t1(`a` INT NOT NULL, `b` INT,
  262. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  263. eval CREATE TABLE t2(`a` INT NOT NULL, `b` INT,
  264. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  265. eval CREATE TABLE t3(`a` INT NOT NULL, `b` INT,
  266. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  267. SET SQL_LOG_BIN= 1;
  268. connection slave;
  269. eval CREATE TABLE t1(`a` INT NOT NULL, `b` INT NOT NULL,
  270. `c` INT NOT NULL,
  271. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  272. eval CREATE TABLE t2(`a` INT NOT NULL, `b` INT NOT NULL,
  273. `c` INT,
  274. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  275. eval CREATE TABLE t3(`a` INT NOT NULL, `b` INT NOT NULL,
  276. `c` INT DEFAULT 500,
  277. PRIMARY KEY(`a`)) ENGINE=$engine DEFAULT CHARSET=LATIN1;
  278. --echo ************* EXECUTION WITH INSERTS *************
  279. connection master;
  280. INSERT INTO t1(a) VALUES (1);
  281. INSERT INTO t1(a, b) VALUES (2, NULL);
  282. INSERT INTO t1(a, b) VALUES (3, 1);
  283. INSERT INTO t2(a) VALUES (1);
  284. INSERT INTO t2(a, b) VALUES (2, NULL);
  285. INSERT INTO t2(a, b) VALUES (3, 1);
  286. INSERT INTO t3(a) VALUES (1);
  287. INSERT INTO t3(a, b) VALUES (2, NULL);
  288. INSERT INTO t3(a, b) VALUES (3, 1);
  289. INSERT INTO t3(a, b) VALUES (4, 1);
  290. REPLACE INTO t3(a, b) VALUES (5, null);
  291. REPLACE INTO t3(a, b) VALUES (3, null);
  292. UPDATE t3 SET b = NULL where a = 4;
  293. --echo ************* SHOWING THE RESULT SETS *************
  294. connection master;
  295. sync_slave_with_master;
  296. connection master;
  297. SELECT * FROM t1 ORDER BY a;
  298. connection slave;
  299. SELECT * FROM t1 ORDER BY a;
  300. connection master;
  301. SELECT * FROM t2 ORDER BY a;
  302. connection slave;
  303. SELECT * FROM t2 ORDER BY a;
  304. connection master;
  305. SELECT * FROM t3 ORDER BY a;
  306. connection slave;
  307. SELECT * FROM t3 ORDER BY a;
  308. connection master;
  309. DROP TABLE t1;
  310. DROP TABLE t2;
  311. DROP TABLE t3;
  312. sync_slave_with_master;