mariadb/mysql-test/t/rpl_user_variables.test

395 lines
9.4 KiB
Text
Raw Normal View History

#
# Test of replicating user variables
#
source include/master-slave.inc;
A lot of fixes for prepared statements (PS): New mysqltest that can run mysqltest with PS Added support for ZEROFILL in PS Fixed crash when one called mysql_stmt_store_result() without a preceding mysql_stmt_bind_result() Updated test cases to support --ps-protocol (Some tests are still run using old protocol) Fixed crash in PS when using SELECT * FROM t1 NATURAL JOIN t2... Fixed crash in PS when using sub queries Create table didn't signal when table was created. This could cause a "DROP TABLE created_table" in another thread to wait "forever" Fixed wrong permissions check in PS and multi-table updates (one could get permission denied for legal quries) Fix for PS and SELECT ... PROCEDURE Reset all warnings when executing a new PS query group_concat(...ORDER BY) didn't work with PS Fixed problem with test suite when not using innodb BitKeeper/deleted/.del-innodb-lock-master.opt~f76a4a1999728f87: Delete: mysql-test/t/innodb-lock-master.opt client/Makefile.am: mysqltest now uses regex client/mysqltest.c: Added support for testing of prepared statements (with --ps-protocol) Main code was done by Kent, I did mainly some cleanups and minor bug fixes New test commands: --disable_ps_protocol --enable_ps_protocol NOTE: new code still has some things that needs to be cleaned up. For example run_query_stmt_handle_error() should be made more general so that same code can be used also by 'normal' queries configure.in: mysqltest now uses regex libmysql/libmysql.c: Reset warning_count after prepare (safety). In the future we should also provide warnings on prepare integer -> string conversion now handles ZEROFILL double -> string conversion is now closer to the one in the server Fixed crash when one called mysql_stmt_store_result() without preceding mysql_stmt_bind_result() libmysqld/examples/Makefile.am: mysqltest now uses regex mysql-test/include/have_query_cache.inc: Fixes for --ps-protocol mysql-test/include/ps_conv.inc: Fixes for --ps-protocol mysql-test/mysql-test-run.sh: Added options --ps-protocol mysql-test/r/ctype_utf8.result: Fixed test case mysql-test/r/fulltext_cache.result: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/r/fulltext_left_join.result: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/r/fulltext_multi.result: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/r/innodb-lock.result: Fixed test to work even if Innodb is not compiled in. mysql-test/t/create.test: Fixes for --ps-protocol mysql-test/t/ctype_utf8.test: Remove warnings mysql-test/t/date_formats.test: Fixes for --ps-protocol mysql-test/t/fulltext_cache.test: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/t/fulltext_left_join.test: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/t/fulltext_multi.test: Changed output of MATCH to use round() to get same numbers with --ps-protocol mysql-test/t/func_group.test: Fixes for --ps-protocol mysql-test/t/func_sapdb.test: Fixes for --ps-protocol mysql-test/t/innodb-lock.test: Fixed test to work even if Innodb is not compiled in. mysql-test/t/insert.test: Fixes for --ps-protocol mysql-test/t/insert_select.test: Fixes for --ps-protocol mysql-test/t/insert_update.test: Fixes for --ps-protocol mysql-test/t/metadata.test: Fixes for --ps-protocol mysql-test/t/multi_statement.test: Fixes for --ps-protocol mysql-test/t/ps_1general.test: Fixes for --ps-protocol mysql-test/t/rollback.test: Fixes for --ps-protocol mysql-test/t/rpl_redirect.test: Fixes for --ps-protocol mysql-test/t/rpl_user_variables.test: Fixes for --ps-protocol mysql-test/t/select.test: Fixes for --ps-protocol mysql-test/t/status.test: Fixes for --ps-protocol mysql-test/t/type_blob.test: Fixes for --ps-protocol mysql-test/t/type_float.test: Fixes for --ps-protocol mysql-test/t/union.test: Fixes for --ps-protocol mysql-test/t/warnings.test: Fixes for --ps-protocol mysys/my_alloc.c: More debugging information sql-common/client.c: More debugging information sql-common/my_time.c: TIME didn't support full range with PS sql/field.cc: TIME didn't support full range with PS sql/item_cmpfunc.cc: IN(constants,...) didn't work with PS sql/item_subselect.cc: Some subqueries didn't work with PS sql/item_sum.cc: group_concat(...ORDER BY) didn't work with PS Removed variable warning_available as 'warning' can be used for this. sql/item_sum.h: Removed not needed variable sql/protocol.cc: TIME didn't support full range with PS sql/set_var.cc: Style fix sql/sql_base.cc: setup_wild() didn't properly restore old arena, which caused core dump in PS when using SELECT * FROM t1 NATURAL JOIN t2... sql/sql_class.cc: Style fix sql/sql_error.cc: Style fix sql/sql_insert.cc: Create table didn't signal when table was created. This could cause a "DROP TABLE created_table" in another thread to wait "forever" sql/sql_lex.h: Fix for PS and procedures sql/sql_parse.cc: More debugging information Make a copy of 'db' in PS as this may change Fixed wrong permissions check in PS and multi-table updates sql/sql_prepare.cc: Fix for PS and SELECT ... PROCEDURE Reset all warnings when executing a new query sql/sql_union.cc: Fixes for PS and SELECT ... PROCEDURE Reset 'with_wild' as 'wild' is resolved on prepare
2004-10-26 18:30:01 +02:00
# Disable PS as the log positions differs
--disable_ps_protocol
# Clean up old slave's binlogs.
# The slave is started with --log-slave-updates
# and this test does SHOW BINLOG EVENTS on the slave's
# binlog. But previous tests can influence the current test's
# binlog (e.g. a temporary table in the previous test has not
# been explicitly deleted, or it has but the slave hasn't had
# enough time to catch it before STOP SLAVE,
# and at the beginning of the current
# test the slave immediately writes DROP TEMPORARY TABLE this_old_table).
# We wait for the slave to have written all he wants to the binlog
# (otherwise RESET MASTER may come too early).
save_master_pos;
connection slave;
sync_with_master;
reset master;
connection master;
create table t1(n char(30));
set @i1:=12345678901234, @i2:=-12345678901234, @i3:=0, @i4:=-1;
set @s1:='This is a test', @r1:=12.5, @r2:=-12.5;
set @n1:=null;
set @s2:='', @s3:='abc\'def', @s4:= 'abc\\def', @s5:= 'abc''def';
insert into t1 values (@i1), (@i2), (@i3), (@i4);
insert into t1 values (@r1), (@r2);
insert into t1 values (@s1), (@s2), (@s3), (@s4), (@s5);
insert into t1 values (@n1);
insert into t1 values (@n2); # not explicitely set before
insert into t1 values (@a:=0), (@a:=@a+1), (@a:=@a+1);
insert into t1 values (@a+(@b:=@a+1));
set @q:='abc';
insert t1 values (@q), (@q:=concat(@q, 'n1')), (@q:=concat(@q, 'n2'));
set @a:=5;
insert into t1 values (@a),(@a);
connection master1; # see if variable is reset in binlog when thread changes
insert into t1 values (@a),(@a),(@a*5);
select * from t1;
save_master_pos;
connection slave;
sync_with_master;
select * from t1;
WL#874 "Extended LOAD DATA". Now one can use user variables as target for data loaded from file (besides table's columns). Also LOAD DATA got new SET-clause in which one can specify values for table columns as expressions. For example the following is possible: LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1; This patch also implements new way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event client/mysqlbinlog.cc: Added support of two new binary log events Begin_load_query_log_event and Execute_load_query_log_Event which are used to replicate LOAD DATA INFILE. mysql-test/r/ctype_ucs.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/insert_select.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/loaddata.result: Added tests for new LOAD DATA features. mysql-test/r/mix_innodb_myisam_binlog.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results (don't dare to get rid from binlog positions completely since it seems that this test uses them). mysql-test/r/mysqlbinlog.result: New approach for binlogging of LOAD DATA statement. Now we store it as usual query and rewrite part in which file is specified when needed. So now mysqlbinlog output for LOAD DATA much more closer to its initial form. Updated test'd results accordingly. mysql-test/r/mysqldump.result: Made test more robust to other tests failures. mysql-test/r/rpl000015.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_change_master.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results. mysql-test/r/rpl_charset.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly mysql-test/r/rpl_deadlock.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly mysql-test/r/rpl_error_ignored_table.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/rpl_flush_log_loop.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_flush_tables.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/rpl_loaddata.result: New way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event... Updated test's results wwith new binlog positions. mysql-test/r/rpl_loaddata_rule_m.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. Since now LOAD DATA is replicated much in the same way as usual query --binlog_do/ignore_db work for it inthe same way as for usual queries. mysql-test/r/rpl_loaddata_rule_s.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_loaddatalocal.result: Added nice test for case when it is important that LOAD DATA LOCAL ignores duplicates. mysql-test/r/rpl_log.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly (don't dare to get rid from binlog positions completely since it seems that this test uses them). mysql-test/r/rpl_log_pos.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_max_relay_size.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_multi_query.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_relayrotate.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_replicate_do.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_reset_slave.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_rotate_logs.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_server_id1.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_server_id2.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly. mysql-test/r/rpl_temporary.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/rpl_timezone.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/rpl_until.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results accordingly and tweaked test a bit to bring it back to good shape. mysql-test/r/rpl_user_variables.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/r/user_var.result: Addition of two new types of binary log events shifted binlog positions. Updated test's results and made it more robust for future similar changes. mysql-test/t/ctype_ucs.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. mysql-test/t/insert_select.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. mysql-test/t/loaddata.test: Added test cases for new LOAD DATA functionality. mysql-test/t/mix_innodb_myisam_binlog.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/mysqlbinlog.test: New way of replicating LOAD DATA local. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event... Thus we need new binlog positions for LOAD DATA events. mysql-test/t/mysqlbinlog2.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/mysqldump.test: Made test more robust for failures of other tests. mysql-test/t/rpl_charset.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/rpl_deadlock.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/rpl_error_ignored_table.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. mysql-test/t/rpl_flush_tables.test: Addition of two new types of binary log events shifted binlog positions. Made test more robust for future similar changes. mysql-test/t/rpl_loaddata.test: New way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event... Apropritely updated comments in test. mysql-test/t/rpl_loaddata_rule_m.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. Since now LOAD DATA is replicated much in the same way as usual query --binlog_do/ignore_db work for it inthe same way as for usual queries. mysql-test/t/rpl_loaddata_rule_s.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/rpl_loaddatalocal.test: Added nice test for case when it is important that LOAD DATA LOCAL ignores duplicates. mysql-test/t/rpl_log.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly (don't dare to get rid from binlog positions completely since it seems that this test uses them). mysql-test/t/rpl_log_pos.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/rpl_multi_query.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly. mysql-test/t/rpl_temporary.test: Addition of two new types of binary log events shifted binlog positions. Made test more robust for future similar changes. mysql-test/t/rpl_timezone.test: Addition of two new types of binary log events shifted binlog positions. Made test more robust for future similar changes. mysql-test/t/rpl_until.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and tweaked it a bit to bring it back to good shape. mysql-test/t/rpl_user_variables.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. mysql-test/t/user_var.test: Addition of two new types of binary log events shifted binlog positions. Updated test accordingly and made it more robust for future similar changes. sql/item_func.cc: Added Item_user_var_as_out_param class that represents user variable which used as out parameter in LOAD DATA. Moved code from Item_func_set_user_var::update_hash() function to separate static function to be able to reuse it in this new class. sql/item_func.h: Added Item_user_var_as_out_param class that represents user variable which used as out parameter in LOAD DATA. sql/log_event.cc: New way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event. sql/log_event.h: New way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event. sql/mysql_priv.h: Now mysql_load() has two more arguments. They are needed to pass list of columns and corresponding expressions from new LOAD DATA's SET clause. sql/share/errmsg.txt: Added new error message which is used to forbid loading of data from fixed length rows to variables. sql/sql_lex.h: Added LEX::fname_start/fname_end members. They are pointers to part of LOAD DATA statement which should be rewritten during replication (file name + little extra). sql/sql_load.cc: Added support for extended LOAD DATA. Now one can use user variables as target for data loaded from file (besides table's columns). Also LOAD DATA got new SET-clause in which one can specify values for table columns as expressions. Updated mysql_load()/read_fixed_length()/read_sep_field() to support this functionality (now they can read data from file to both columns and variables and assign do calculations and assignments specified in SET clause). We also use new approach for LOAD DATA binlogging/replication. sql/sql_parse.cc: mysql_execute_command(): Since now we have SET clause in LOAD DATA we should also check permissions for tables used in its expressions. Also mysql_load() has two more arguments to pass information about this clause. sql/sql_repl.cc: New way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event. sql/sql_repl.h: struct st_load_file_info: Removed memebers which are no longer needed for LOAD DATA binnlogging. sql/sql_yacc.yy: Added support for extended LOAD DATA syntax. Now one can use user variables as target for data loaded from file (besides table's columns). Also LOAD DATA got new SET-clause in which one can specify values for table columns as expressions. For example the following is possible: LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1; Also now we save pointers to the beginning and to the end of part of LOAD DATA statement which should be rewritten during replication.
2005-03-16 02:32:47 +01:00
--replace_column 2 # 5 #
show binlog events from 98;
#
# BUG19136: Crashing log-bin and uninitialized user variables in a derived table
# just to check nothing bad happens anymore
#
connection master;
insert into t1 select * FROM (select @var1 union select @var2) AS t2;
drop table t1;
save_master_pos;
BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables. mysql-test/r/rpl_user_variables.result: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the correct results for execution of the added test procedures to the rpl_user_variables test. mysql-test/t/rpl_user_variables.test: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds additional tests to the rpl_user_variables test that test many of the different ways user-defined variables can be required to be replicated. sql/item_func.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. To properly log accesses to user-defined variables from stored functions/triggers, the get_var_with_binlog() method needs to log references to such variables even from non-table-updating statements within them. sql/log.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the start_union_events method to accept the query id from a parameter. This allows callers to set the query_id to the id of the sub statement such as a trigger or stored function. Which permits the code to identify when a user defined variable has been used by the statement and this already present in THD::user_var_event. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sp_head.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the code to allow for cases where events for function calls have a separate union for each event and thus cannot use the query_id of the caller as the start of the union. Thus, we use an artifically created query_id to set the start of the events. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events(). Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.h: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events().
2007-02-23 18:58:56 +01:00
--echo End of 4.1 tests.
# BUG#20141
# The following tests ensure that if user-defined variables are used in SF/Triggers
# that they are replicated correctly. These tests should be run in both SBR and RBR
# modes.
# This test uses a procedure that inserts data values based on the value of a
# user-defined variable. It also has a trigger that inserts data based on the
# same variable. Successful test runs show that the @var is replicated
# properly and that the procedure and trigger insert the correct data on the
# slave.
#
# The test of stored procedure was included for completeness. Replication of stored
# procedures was not directly affected by BUG#20141.
#
# This test was constructed for BUG#20141
--disable_warnings
DROP TABLE IF EXISTS t20;
DROP TABLE IF EXISTS t21;
DROP PROCEDURE IF EXISTS test.insert;
--enable_warnings
CREATE TABLE t20 (a VARCHAR(20));
CREATE TABLE t21 (a VARCHAR(20));
DELIMITER |;
# Create a procedure that uses the @var for flow control
CREATE PROCEDURE test.insert()
BEGIN
IF (@VAR)
THEN
INSERT INTO test.t20 VALUES ('SP_TRUE');
ELSE
INSERT INTO test.t20 VALUES ('SP_FALSE');
END IF;
END|
# Create a trigger that uses the @var for flow control
CREATE TRIGGER test.insert_bi BEFORE INSERT
ON test.t20 FOR EACH ROW
BEGIN
IF (@VAR)
THEN
INSERT INTO test.t21 VALUES ('TRIG_TRUE');
ELSE
INSERT INTO test.t21 VALUES ('TRIG_FALSE');
END IF;
END|
DELIMITER ;|
sync_slave_with_master;
connection master;
# Set @var and call the procedure, repeat with different values
SET @VAR=0;
CALL test.insert();
SET @VAR=1;
CALL test.insert();
--echo On master: Check the tables for correct data
SELECT * FROM t20;
SELECT * FROM t21;
sync_slave_with_master;
--echo On slave: Check the tables for correct data and it matches master
SELECT * FROM t20;
SELECT * FROM t21;
connection master;
# Cleanup
DROP TABLE t20;
DROP TABLE t21;
DROP PROCEDURE test.insert;
# This test uses a stored function that uses user-defined variables to return data
# This test was constructed for BUG#20141
--disable_warnings
DROP TABLE IF EXISTS t1;
DROP FUNCTION IF EXISTS test.square;
--enable_warnings
CREATE TABLE t1 (i INT);
# Create function that returns a value from @var. In this case, the square function
CREATE FUNCTION test.square() RETURNS INTEGER DETERMINISTIC RETURN (@var * @var);
sync_slave_with_master;
connection master;
# Set the @var to different values and insert them into a table
SET @var = 1;
INSERT INTO t1 VALUES (square());
SET @var = 2;
INSERT INTO t1 VALUES (square());
SET @var = 3;
INSERT INTO t1 VALUES (square());
SET @var = 4;
INSERT INTO t1 VALUES (square());
SET @var = 5;
INSERT INTO t1 VALUES (square());
--echo On master: Retrieve the values from the table
SELECT * FROM t1;
sync_slave_with_master;
--echo On slave: Retrieve the values from the table and verify they are the same as on master
SELECT * FROM t1;
connection master;
# Cleanup
DROP TABLE t1;
DROP FUNCTION test.square;
# This test uses stored functions that uses user-defined variables to return data
# based on the use of @vars inside a function body.
# This test was constructed for BUG#14914
--disable_warnings
DROP TABLE IF EXISTS t1;
DROP FUNCTION IF EXISTS f1;
DROP FUNCTION IF EXISTS f2;
--enable_warnings
CREATE TABLE t1(a int);
DELIMITER |;
# Create a function that simply returns the value of an @var.
# Create a function that uses an @var for flow control, creates and uses another
# @var and sets its value to a value based on another @var.
CREATE FUNCTION f1() returns int deterministic
BEGIN
return @a;
END |
CREATE FUNCTION f2() returns int deterministic
BEGIN
IF (@b > 0) then
SET @c = (@a + @b);
else
SET @c = (@a - 1);
END if;
return @c;
END |
DELIMITER ;|
sync_slave_with_master;
connection master;
# Set an @var to a value and insert data into a table using the first function.
# Set two more @vars to some values and insert data into a table using the second function.
SET @a=500;
INSERT INTO t1 values(f1());
SET @b = 125;
SET @c = 1;
INSERT INTO t1 values(f2());
sync_slave_with_master;
--echo On master: Retrieve the values from the table
SELECT * from t1;
--echo On slave: Check the tables for correct data and it matches master
SELECT * from t1;
connection master;
# Cleanup
DROP TABLE t1;
DROP FUNCTION f1;
DROP FUNCTION f2;
# This test uses a function that changes a user-defined variable in its body. This test
# will ensure the @vars are replicated when needed and not interrupt the normal execution
# of the function on the slave. This also applies to triggers.
#
# This test was constructed for BUG#25167
--disable_warnings
DROP TABLE IF EXISTS t1;
DROP TABLE IF EXISTS t2;
--enable_warnings
CREATE TABLE t1 (i int);
CREATE TABLE t2 (k int);
DELIMITER |;
# Create a trigger that inserts data into another table, changes the @var then inserts
# another row with the modified value.
CREATE trigger t1_bi before INSERT on t1 for each row
BEGIN
INSERT INTO t2 values (@a);
SET @a:=42;
INSERT INTO t2 values (@a);
END |
DELIMITER ;|
sync_slave_with_master;
connection master;
# Set the @var to a value then insert data into first table.
SET @a:=100;
INSERT INTO t1 values (5);
--echo On master: Check to see that data was inserted correctly in both tables
SELECT * from t1;
SELECT * from t2;
sync_slave_with_master;
--echo On slave: Check the tables for correct data and it matches master
SELECT * from t1;
SELECT * from t2;
connection master;
Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements Problem: binlogging PS' we may produce syntacticly incorrect queries in the binlog replacing some parameters with variable names (instead of variable values). E.g. in the reported case of "limit ?" clause: replacing "?" with "@var" produces "limit @var" which is not a correct SQL syntax. Also it may lead to different query execution on slave if we set and use a variable in the same statement, e.g. "insert into t1 values (@x:=@x+1, ?)" Fix: make the stored statement string created upon its execution use variable values (instead of names) to fill placeholders. mysql-test/r/ctype_cp932_binlog.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/ctype_cp932_notembedded.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/rpl_user_variables.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test result. mysql-test/t/ctype_cp932_binlog.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test adjusted. mysql-test/t/rpl_user_variables.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test case. sql/sql_prepare.cc: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - set val to the variable's value (escaped if needed) then insert it into the query string in the position of the placeholder. We don't need to call get_var_with_binlog() here as there is no trace of the variable's name in the binlog.
2007-05-24 12:35:43 +02:00
drop table t1, t2;
BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables. mysql-test/r/rpl_user_variables.result: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the correct results for execution of the added test procedures to the rpl_user_variables test. mysql-test/t/rpl_user_variables.test: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds additional tests to the rpl_user_variables test that test many of the different ways user-defined variables can be required to be replicated. sql/item_func.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. To properly log accesses to user-defined variables from stored functions/triggers, the get_var_with_binlog() method needs to log references to such variables even from non-table-updating statements within them. sql/log.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the start_union_events method to accept the query id from a parameter. This allows callers to set the query_id to the id of the sub statement such as a trigger or stored function. Which permits the code to identify when a user defined variable has been used by the statement and this already present in THD::user_var_event. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sp_head.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the code to allow for cases where events for function calls have a separate union for each event and thus cannot use the query_id of the caller as the start of the union. Thus, we use an artifically created query_id to set the start of the events. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events(). Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.h: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events().
2007-02-23 18:58:56 +01:00
Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements Problem: binlogging PS' we may produce syntacticly incorrect queries in the binlog replacing some parameters with variable names (instead of variable values). E.g. in the reported case of "limit ?" clause: replacing "?" with "@var" produces "limit @var" which is not a correct SQL syntax. Also it may lead to different query execution on slave if we set and use a variable in the same statement, e.g. "insert into t1 values (@x:=@x+1, ?)" Fix: make the stored statement string created upon its execution use variable values (instead of names) to fill placeholders. mysql-test/r/ctype_cp932_binlog.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/ctype_cp932_notembedded.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/rpl_user_variables.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test result. mysql-test/t/ctype_cp932_binlog.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test adjusted. mysql-test/t/rpl_user_variables.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test case. sql/sql_prepare.cc: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - set val to the variable's value (escaped if needed) then insert it into the query string in the position of the placeholder. We don't need to call get_var_with_binlog() here as there is no trace of the variable's name in the binlog.
2007-05-24 12:35:43 +02:00
#
# Bug #26842: master binary log contains invalid queries - replication fails
#
save_master_pos;
connection slave;
sync_with_master;
reset master;
BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables. mysql-test/r/rpl_user_variables.result: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the correct results for execution of the added test procedures to the rpl_user_variables test. mysql-test/t/rpl_user_variables.test: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds additional tests to the rpl_user_variables test that test many of the different ways user-defined variables can be required to be replicated. sql/item_func.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. To properly log accesses to user-defined variables from stored functions/triggers, the get_var_with_binlog() method needs to log references to such variables even from non-table-updating statements within them. sql/log.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the start_union_events method to accept the query id from a parameter. This allows callers to set the query_id to the id of the sub statement such as a trigger or stored function. Which permits the code to identify when a user defined variable has been used by the statement and this already present in THD::user_var_event. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sp_head.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the code to allow for cases where events for function calls have a separate union for each event and thus cannot use the query_id of the caller as the start of the union. Thus, we use an artifically created query_id to set the start of the events. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events(). Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.h: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events().
2007-02-23 18:58:56 +01:00
Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements Problem: binlogging PS' we may produce syntacticly incorrect queries in the binlog replacing some parameters with variable names (instead of variable values). E.g. in the reported case of "limit ?" clause: replacing "?" with "@var" produces "limit @var" which is not a correct SQL syntax. Also it may lead to different query execution on slave if we set and use a variable in the same statement, e.g. "insert into t1 values (@x:=@x+1, ?)" Fix: make the stored statement string created upon its execution use variable values (instead of names) to fill placeholders. mysql-test/r/ctype_cp932_binlog.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/ctype_cp932_notembedded.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/rpl_user_variables.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test result. mysql-test/t/ctype_cp932_binlog.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test adjusted. mysql-test/t/rpl_user_variables.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test case. sql/sql_prepare.cc: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - set val to the variable's value (escaped if needed) then insert it into the query string in the position of the placeholder. We don't need to call get_var_with_binlog() here as there is no trace of the variable's name in the binlog.
2007-05-24 12:35:43 +02:00
connection master;
create table t1 (a int);
prepare s from "insert into t1 values (@a),(?)";
set @a=98; execute s using @a;
prepare s from "insert into t1 values (?)";
set @a=99; execute s using @a;
prepare s from "insert into t1 select 100 limit ?";
set @a=100; execute s using @a;
BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables. mysql-test/r/rpl_user_variables.result: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the correct results for execution of the added test procedures to the rpl_user_variables test. mysql-test/t/rpl_user_variables.test: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds additional tests to the rpl_user_variables test that test many of the different ways user-defined variables can be required to be replicated. sql/item_func.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. To properly log accesses to user-defined variables from stored functions/triggers, the get_var_with_binlog() method needs to log references to such variables even from non-table-updating statements within them. sql/log.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the start_union_events method to accept the query id from a parameter. This allows callers to set the query_id to the id of the sub statement such as a trigger or stored function. Which permits the code to identify when a user defined variable has been used by the statement and this already present in THD::user_var_event. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sp_head.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the code to allow for cases where events for function calls have a separate union for each event and thus cannot use the query_id of the caller as the start of the union. Thus, we use an artifically created query_id to set the start of the events. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events(). Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.h: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events().
2007-02-23 18:58:56 +01:00
Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements Problem: binlogging PS' we may produce syntacticly incorrect queries in the binlog replacing some parameters with variable names (instead of variable values). E.g. in the reported case of "limit ?" clause: replacing "?" with "@var" produces "limit @var" which is not a correct SQL syntax. Also it may lead to different query execution on slave if we set and use a variable in the same statement, e.g. "insert into t1 values (@x:=@x+1, ?)" Fix: make the stored statement string created upon its execution use variable values (instead of names) to fill placeholders. mysql-test/r/ctype_cp932_binlog.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/ctype_cp932_notembedded.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - result adjusted. mysql-test/r/rpl_user_variables.result: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test result. mysql-test/t/ctype_cp932_binlog.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test adjusted. mysql-test/t/rpl_user_variables.test: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - test case. sql/sql_prepare.cc: Fix for bug #26842: master binary log contains invalid queries - replication fails bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements - set val to the variable's value (escaped if needed) then insert it into the query string in the position of the placeholder. We don't need to call get_var_with_binlog() here as there is no trace of the variable's name in the binlog.
2007-05-24 12:35:43 +02:00
save_master_pos;
connection slave;
sync_with_master;
show binlog events from 98;
select * from t1;
connection master;
drop table t1;
#
# Bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements
#
connection master;
create table t1(a int, b int);
prepare s1 from 'insert into t1 values (@x:=@x+1, ?)';
set @x=1; execute s1 using @x;
select * from t1;
sync_slave_with_master;
connection slave;
select * from t1;
connection master;
drop table t1;
--echo End of 5.0 tests.
BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables. mysql-test/r/rpl_user_variables.result: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the correct results for execution of the added test procedures to the rpl_user_variables test. mysql-test/t/rpl_user_variables.test: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds additional tests to the rpl_user_variables test that test many of the different ways user-defined variables can be required to be replicated. sql/item_func.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. To properly log accesses to user-defined variables from stored functions/triggers, the get_var_with_binlog() method needs to log references to such variables even from non-table-updating statements within them. sql/log.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the start_union_events method to accept the query id from a parameter. This allows callers to set the query_id to the id of the sub statement such as a trigger or stored function. Which permits the code to identify when a user defined variable has been used by the statement and this already present in THD::user_var_event. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sp_head.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch modifies the code to allow for cases where events for function calls have a separate union for each event and thus cannot use the query_id of the caller as the start of the union. Thus, we use an artifically created query_id to set the start of the events. Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.cc: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events(). Note: The changes to sql_class.cc, sp_head.cc, and log.cc are designed to allow the proper replication of access to user-defined variables under a special test case (the last case shown in rpl_user_variables.test). sql/sql_class.h: BUG#20141 - User-defined variables are not replicated properly for SF/Triggers in SBR mode. This patch adds the query_id parameter to the calls to mysql_bin_log.start_union_events().
2007-02-23 18:58:56 +01:00
# This test uses a stored function that uses user-defined variables to return data
# The test ensures the value of the user-defined variable is replicated correctly
# and in the correct order of assignment.
# This test was constructed for BUG#20141
--disable_warnings
DROP FUNCTION IF EXISTS f1;
DROP FUNCTION IF EXISTS f2;
--enable_warnings
CREATE TABLE t1 (i INT);
# Create two functions. One simply returns the user-defined variable. The other
# returns a value based on the user-defined variable.
CREATE FUNCTION f1() RETURNS INT RETURN @a;
DELIMITER |;
CREATE FUNCTION f2() RETURNS INT
BEGIN
INSERT INTO t1 VALUES (10 + @a);
RETURN 0;
END|
DELIMITER ;|
sync_slave_with_master;
connection master;
# Set the variable and execute the functions.
SET @a:=123;
SELECT f1(), f2();
--echo On master: Check to see that data was inserted correctly
INSERT INTO t1 VALUES(f1());
SELECT * FROM t1;
sync_slave_with_master;
--echo On slave: Check the table for correct data and it matches master
SELECT * FROM t1;
connection master;
# Cleanup
DROP FUNCTION f1;
DROP FUNCTION f2;
DROP TABLE t1;
sync_slave_with_master;
stop slave;