mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-19 21:42:35 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/extra/binlog_tests/binlog_insert_delayed.test

41 lines
1.4 KiB
Text
Raw Normal View History

Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
# Test of binlogging of INSERT_ID with INSERT DELAYED
create table t1 (a int not null auto_increment, primary key (a)) engine=myisam;
# First, avoid BUG#20627:
set @@session.auto_increment_increment=1, @@session.auto_increment_offset=1;
# Verify that only one INSERT_ID event is binlogged.
# Note, that because of WL#3368 mixed mode binlog records RBR events for the delayed
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
let $table=t1;
let $rows_inserted=11; # total number of inserted rows in this test
Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
insert delayed into t1 values (207);
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
let $count=1;
Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
# use this macro instead of sleeps.
--source include/wait_until_rows_count.inc
Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
insert delayed into t1 values (null);
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
inc $count;
--source include/wait_until_rows_count.inc
Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
insert delayed into t1 values (300);
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
inc $count;
--source include/wait_until_rows_count.inc
One more fix for binlog_row_binlog due to interminism of checking with SHOW BINLOG event. The latter should be either fixed or replaced to favor reading from binlog as the check.
2006-09-27 12:05:29 +02:00
# moving binlog check affront of multi-rows queries which work is indeterministic (extra table_maps)
# todo: better check is to substitute SHOW BINLOG with reading from binlog, probably bug#19459 is in
# the way
Merge romeo.(none):/home/bkroot/mysql-5.1-new-rpl into romeo.(none):/home/bk/w3464-mysql-5.1-new-rpl
2007-03-29 21:38:03 +02:00
source include/show_binlog_events.inc;
One more fix for binlog_row_binlog due to interminism of checking with SHOW BINLOG event. The latter should be either fixed or replaced to favor reading from binlog as the check.
2006-09-27 12:05:29 +02:00
Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL#3146; let's not be sad, that monster push still removed serious bugs): one problem with INSERT DELAYED (unexpected interval releases), one with stored functions (wrong auto_inc binlogging). These bugs were not released.
2006-09-12 15:42:13 +02:00
insert delayed into t1 values (null),(null),(null),(null);
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
inc $count; inc $count; inc $count; inc $count;
--source include/wait_until_rows_count.inc
Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL#3146; let's not be sad, that monster push still removed serious bugs): one problem with INSERT DELAYED (unexpected interval releases), one with stored functions (wrong auto_inc binlogging). These bugs were not released.
2006-09-12 15:42:13 +02:00
insert delayed into t1 values (null),(null),(400),(null);
binlog_row_binlog test gained some indeterministic checks with changes due to ChangeSet@1.2309.1.12, 2006-09-12 15:42:13+02:00, guilhem@gbichot3.local +14 -0 Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL #3146; ... The problem is in that show binlog events in indeterministic, row events can be compressed, so that 2 seconds original delay does not guard from inconsistency. We syncronize test's current inserted rows counter with system insert delayed thread per each query. From another side there is no requirement for binlog to be event per row and then to verify if binlog has recorded what was recently inserted is better via reading from it instead of 'show binlog events'.
2006-09-23 14:24:45 +02:00
inc $count; inc $count; inc $count; inc $count;
--source include/wait_until_rows_count.inc
#check this assertion about $count calculation
--echo $count == $rows_inserted
Changes made according to HLD/LLD. The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
2006-08-30 09:22:43 +02:00
select * from t1;
drop table t1;
Reference in a new issue Copy permalink