mariadb/mysql-test/suite/binlog/r/binlog_killed.result

144 lines
3.4 KiB
Text
Raw Normal View History

Bug#22725 Replication outages from ER_SERVER_SHUTDOWN (1053) set in replication events The reason for the bug was that replaying of a query on slave could not be possible since its event was recorded with the killed error. Due to the specific of handling INSERT, which per-row-while-loop is unbreakable to killing, the query on transactional table should have not appeared in binlog unless there was a call to a stored routine that got interrupted with killing (and then there must be an error returned out of the loop). The offered solution added the following rule for binlogging of INSERT that accounts the above specifics: For INSERT on transactional-table if the error was not set the only raised flag is harmless and is ignored via masking out on time of creation of binlog event. For both table types the combination of raised error and KILLED flag indicates that there was potentially partial execution on master and consistency is under the question. In that case the code continues to binlog an event with an appropriate killed error. The fix relies on the specified behaviour of stored routine that must propagate the error to the top level query handling if the thd->killed flag was raised in the routine execution. The patch adds an arg with the default killed-status-unset value to Query_log_event::Query_log_event. sql/log_event.cc: killed_status as the value of thd->killed can be passed as an arg to the constructor. if the value is different from the default the arg is set to the current thd->killed value. A caller might need to masquerade thd->killed with THD::NOT_KILLED. So far only mysql_insert() uses such explicit way to tell the constructor about killing status. sql/log_event.h: default arg to the constructor with meaning of killed status of the query. if the arg is not explicitly provided the status of thd->killed will be snapshot inside of the constuctor, which is potentially incorrect (see bug#27571) sql/sql_class.h: extending killed_state with no-state member. sql/sql_insert.cc: ignore the KILLED flag incl KILL_BAD_DATA when the INSERT query event is created without an `error'; sql/sql_update.cc: Suggestion how to fix bug#27571 as comments. mysql-test/r/binlog_killed.result: new result file mysql-test/t/binlog_killed.test: regression tests also apply for bug27563, BUG#27565
2007-05-28 21:20:22 +02:00
create table t1 (a int auto_increment, b int, PRIMARY KEY (a)) ENGINE=InnoDB;
create table t2 (a int auto_increment, b int, PRIMARY KEY (a)) ENGINE=MyISAM;
create table t3 (a int auto_increment, b int, PRIMARY KEY (a)) ENGINE=InnoDB;
select get_lock("a", 20);
get_lock("a", 20)
1
reset master;
insert into t2 values (null, null), (null, get_lock("a", 10));
select @result /* must be zero either way */;
@result
0
select RELEASE_LOCK("a");
RELEASE_LOCK("a")
1
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
delete from t1;
delete from t2;
insert into t1 values (1,1),(2,2);
begin;
update t1 set b=11 where a=2;
begin;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
update t1 set b=b+10;
kill query ID;
rollback;
rollback;
select * from t1 order by a /* must be the same as before (1,1),(2,2) */;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
a b
1 1
2 2
begin;
delete from t1 where a=2;
begin;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
delete from t1 where a=2;
kill query ID;
rollback;
rollback;
select * from t1 order by a /* must be the same as before (1,1),(2,2) */;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
a b
1 1
2 2
drop table if exists t4;
create table t4 (a int, b int) engine=innodb;
insert into t4 values (3, 3);
begin;
insert into t1 values (3, 3);
begin;
insert into t1 select * from t4 for update;
kill query ID;
rollback;
rollback;
select * from t1 /* must be the same as before (1,1),(2,2) */;
a b
1 1
2 2
drop table t4;
create table t4 (a int, b int) ENGINE=MyISAM /* for killing update and delete */;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
create function bug27563(n int)
RETURNS int(11)
DETERMINISTIC
begin
if @b > 0 then
select get_lock("a", 20) into @a;
else
set @b= 1;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
end if;
return n;
end|
delete from t4;
insert into t4 values (1,1), (1,1);
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
reset master;
select get_lock("a", 20);
get_lock("a", 20)
1
set @b= 0;
update t4 set b=b + bug27563(b);
select count(*) FROM INFORMATION_SCHEMA.PROCESSLIST where state='User lock';
count(*)
1
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
kill query ID;
ERROR 70100: Query execution was interrupted
select * from t4 order by b /* must be (1,1), (1,2) */;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
a b
1 1
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
1 2
select @b /* must be 1 at the end of a stmt calling bug27563() */;
@b
1
must have the update query event more to FD
show binlog events from <binlog_start>;
Log_name Pos Event_type Server_id End_log_pos Info
master-bin.000001 # User var # # @`b`=0
master-bin.000001 # Query # # use `test`; update t4 set b=b + bug27563(b)
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
select
(@a:=load_file("MYSQLTEST_VARDIR/tmp/binlog_killed_bug27571.binlog"))
is not null;
(@a:=load_file("MYSQLTEST_VARDIR/tmp/binlog_killed_bug27571.binlog"))
is not null
1
select 0 /* must return 0 to mean the killed query is in */;
0
0
select RELEASE_LOCK("a");
RELEASE_LOCK("a")
1
delete from t4;
insert into t4 values (1,1), (2,2);
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
reset master;
select get_lock("a", 20);
get_lock("a", 20)
1
set @b= 0;
delete from t4 where b=bug27563(1) or b=bug27563(2);
select count(*) FROM INFORMATION_SCHEMA.PROCESSLIST where state='User lock';
count(*)
1
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
kill query ID;
ERROR 70100: Query execution was interrupted
select count(*) from t4 /* must be 1 */;
count(*)
1
select @b /* must be 1 at the end of a stmt calling bug27563() */;
@b
1
must have the delete query event more to FD
show binlog events from <binlog_start>;
Log_name Pos Event_type Server_id End_log_pos Info
master-bin.000001 # User var # # @`b`=0
master-bin.000001 # Query # # use `test`; delete from t4 where b=bug27563(1) or b=bug27563(2)
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
select
(@a:=load_file("MYSQLTEST_VARDIR/tmp/binlog_killed_bug27571.binlog"))
is not null;
(@a:=load_file("MYSQLTEST_VARDIR/tmp/binlog_killed_bug27571.binlog"))
is not null
1
select 0 /* must return 0 to mean the killed query is in */;
0
0
select RELEASE_LOCK("a");
RELEASE_LOCK("a")
1
drop table t4;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
drop function bug27563;
Bug#22725 Replication outages from ER_SERVER_SHUTDOWN (1053) set in replication events The reason for the bug was that replaying of a query on slave could not be possible since its event was recorded with the killed error. Due to the specific of handling INSERT, which per-row-while-loop is unbreakable to killing, the query on transactional table should have not appeared in binlog unless there was a call to a stored routine that got interrupted with killing (and then there must be an error returned out of the loop). The offered solution added the following rule for binlogging of INSERT that accounts the above specifics: For INSERT on transactional-table if the error was not set the only raised flag is harmless and is ignored via masking out on time of creation of binlog event. For both table types the combination of raised error and KILLED flag indicates that there was potentially partial execution on master and consistency is under the question. In that case the code continues to binlog an event with an appropriate killed error. The fix relies on the specified behaviour of stored routine that must propagate the error to the top level query handling if the thd->killed flag was raised in the routine execution. The patch adds an arg with the default killed-status-unset value to Query_log_event::Query_log_event. sql/log_event.cc: killed_status as the value of thd->killed can be passed as an arg to the constructor. if the value is different from the default the arg is set to the current thd->killed value. A caller might need to masquerade thd->killed with THD::NOT_KILLED. So far only mysql_insert() uses such explicit way to tell the constructor about killing status. sql/log_event.h: default arg to the constructor with meaning of killed status of the query. if the arg is not explicitly provided the status of thd->killed will be snapshot inside of the constuctor, which is potentially incorrect (see bug#27571) sql/sql_class.h: extending killed_state with no-state member. sql/sql_insert.cc: ignore the KILLED flag incl KILL_BAD_DATA when the INSERT query event is created without an `error'; sql/sql_update.cc: Suggestion how to fix bug#27571 as comments. mysql-test/r/binlog_killed.result: new result file mysql-test/t/binlog_killed.test: regression tests also apply for bug27563, BUG#27565
2007-05-28 21:20:22 +02:00
drop table t1,t2,t3;
Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing. mysql-test/r/binlog_killed.result: results changed mysql-test/t/binlog_killed.test: Demonstrating that effective killing during rows-loop execution leads to the speficied actions: binlogging with the error for a query modified a not-transactional table or rolling back effects for transactional table; fixing possible non-determinism with ID when query_log_enabled; leave commented out tests for multi-update,delete due to another bug; removing an obsolete tests template; changing system rm to --remove_file. sql/log_event.cc: adding killed status arg sql/log_event.h: added killed status arg sql/sql_delete.cc: deploying the update part patch for delete, multi-delete sql/sql_insert.cc: deploying the update-part patch for insert..select sql/sql_load.cc: deploying the update-part patch for load data. simulation added. sql/sql_update.cc: Impementing the fix as described in the comments left by bug@22725. Also simulation of killing after the loop that would affect binlogging in the old code. mysql-test/t/binlog_killed_bug27571-master.opt: post rows-loop killing simulation's options mysql-test/t/binlog_killed_bug27571.test: Checking that if killing happens inbetween of the end of rows loop and recording into binlog that will not lead to recording any error incl the killed error. mysql-test/t/binlog_killed_simulate-master.opt: simulation options mysql-test/t/binlog_killed_simulate.test: tests for a query (update is choosen) being killed after the row-loop; load data killed within the loop - effective killed error in the event is gained.
2007-10-29 14:20:59 +01:00
end of the tests