BUG#11758262 BUG#13043055

Problem: commit_1innodb fails on pb2 after the patch for BUG#11758262
Background: Certain statements threw warnings only in statement mode causing
the result cintent mismatch.

Fix: disabled warnings from the statements.
This commit is contained in:
Rohit Kalhans 2011-09-30 15:16:35 +05:30
parent f03a55cc5b
commit 132c41604a
2 changed files with 6 additions and 4 deletions

View file

@ -521,7 +521,9 @@ commit;
call p_verify_status_increment(2, 2, 2, 2);
--echo # 15. Read-write statement: UPDATE IGNORE, change 0 rows.
--echo #
--disable_warnings
update ignore t1 set a=2 where a=1;
--enable_warnings
call p_verify_status_increment(2, 2, 1, 0);
commit;
call p_verify_status_increment(2, 2, 1, 0);
@ -603,7 +605,9 @@ call p_verify_status_increment(2, 0, 1, 0);
--echo # 21. Read-write statement: UPDATE, change 0 (transactional) rows.
--echo #
--disable_warnings
update t1 set a=2 where a=f1()+10;
--enable_warnings
call p_verify_status_increment(2, 0, 1, 0);
commit;
call p_verify_status_increment(2, 0, 1, 0);
@ -703,7 +707,9 @@ call p_verify_status_increment(4, 4, 4, 4);
--echo #
insert into t2 select a from t1;
commit;
--disable_warnings
replace into t2 select a from t1;
--enable_warnings
commit;
call p_verify_status_increment(8, 8, 8, 8);
#

View file

@ -549,8 +549,6 @@ SUCCESS
# 15. Read-write statement: UPDATE IGNORE, change 0 rows.
#
update ignore t1 set a=2 where a=1;
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. UPDATE IGNORE is unsafe because the order in which rows are updated determines which (if any) rows are ignored. This order cannot be predicted and may differ on master and the slave.
call p_verify_status_increment(2, 2, 1, 0);
SUCCESS
@ -816,8 +814,6 @@ SUCCESS
insert into t2 select a from t1;
commit;
replace into t2 select a from t1;
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. REPLACE... SELECT is unsafe because the order in which rows are retrieved by the SELECT determines which (if any) rows are replaced. This order cannot be predicted and may differ on master and the slave.
commit;
call p_verify_status_increment(8, 8, 8, 8);
SUCCESS