mariadb/mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test
Alexander Nozdrin ab61c15efd BUG#50767: Some RPL tests started to fail in next-mr-merge on
Linux x86_64 debug

Two test cases fail because the suppression for the unsafe
warning needs to be updated (BUG@39934 refactored this part and
these changes are only in mysql-next-mr - this is why we notice
them now when merging in next-mr). This is the case for
rpl_nondeterministic_functions and rpl_misc_functions test
cases. rpl_stm_binlog_direct test case is not needed in version >
5.1. The rpl_heartbeat_basic test case fails because patch for
BUG@50397 removed the CHANGE MASTER in the slave that would set
it's period to 1/10 of the master. This would cause the test
assertion to fail.

The fixes for the issues described above are:

 - rpl_misc_functions - updated suppression message
 - rpl_nondeterministic_functions - updated suppression message
 - rpl_stm_binlog_direct - removed the test case (it is not 
                           needed in versions > 5.1)
 - rpl_heartbeat_basic - deployed instruction: 
   CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD=0.1;
2010-02-02 12:26:28 +03:00

57 lines
1.5 KiB
Text

# ==== Purpose ====
#
# Test that nondeterministic system functions are correctly replicated.
#
# (Some functions are only correctly replicated if binlog_format=MIXED
# or ROW. See binlog_unsafe.test for a test that those variables are
# indeed unsafe.)
#
# ==== Implementation ====
#
# We insert the values of each unsafe function into a table. Then we
# replicate and check that the table is identical on slave.
#
# ==== Related bugs ====
#
# BUG#47995
--source include/master-slave.inc
CALL mtr.add_suppression('Unsafe statement binlogged in statement format since BINLOG_FORMAT = STATEMENT');
CREATE TABLE t1 (a VARCHAR(1000));
# We replicate the connection_id in the query_log_event
INSERT INTO t1 VALUES (CONNECTION_ID());
--connection master1
INSERT INTO t1 VALUES (CONNECTION_ID());
# We replicate the TIMESTAMP variable, so the following functions that
# are affected by the TIMESTAMP variable should be safe to replicate.
INSERT INTO t1 VALUES
(CURDATE()),
(CURRENT_DATE()),
(CURRENT_TIME()),
(CURRENT_TIMESTAMP()),
(CURTIME()),
(LOCALTIME()),
(LOCALTIMESTAMP()),
(NOW()),
(UNIX_TIMESTAMP()),
(UTC_DATE()),
(UTC_TIME()),
(UTC_TIMESTAMP());
# We replicate the random seed in a rand_log_event
--disable_warnings
INSERT INTO t1 VALUES (RAND());
--enable_warnings
# We replicate the last_insert_id in an intvar_log_event
INSERT INTO t1 VALUES (LAST_INSERT_ID());
--sync_slave_with_master
--let $diff_table_1= master:test.t1
--let $diff_table_2= slave:test.t1
--source include/diff_tables.inc
DROP TABLE t1;