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

65 lines
2.2 KiB
Text
Raw Normal View History

BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
# ==== Purpose ====
#
# Verify that INSERT DELAYED in mixed or row mode writes events to the
# binlog, and that AUTO_INCREMENT works correctly.
#
# ==== Method ====
#
# Insert both single and multiple rows into an autoincrement column,
# both with specified value and with NULL.
#
# With INSERT DELAYED, the rows do not show up in the table
# immediately, so we must do source include/wait_until_rows_count.inc
# between any two INSERT DELAYED statements. Moreover, if mixed or
# row-based logging is used, there is also a delay between when rows
# show up in the table and when they show up in the binlog. To ensure
# that the rows show up in the binlog, we call FLUSH TABLES, which
# waits until the delayed_insert thread has finished.
#
# We cannot read the binlog after executing INSERT DELAYED statements
# that insert multiple rows, because that is nondeterministic. More
# precisely, rows may be written in batches to the binlog, where each
# batch has one Table_map_log_event and one or more
# Write_rows_log_event. The number of rows included in each batch is
# nondeterministic.
#
# ==== Related bugs ====
#
# BUG#20627: INSERT DELAYED does not honour auto_increment_* variables
# Bug in this test: BUG#38068: binlog_stm_binlog fails sporadically in pushbuild
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
create table t1 (a int not null auto_increment, primary key (a)) engine=myisam;
BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
let $table=t1;
let $count=0;
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
BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
insert delayed into t1 values (207);
inc $count;
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
--source include/wait_until_rows_count.inc
BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
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
BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
# It is not enough to wait until all rows have been inserted into the
# table. FLUSH TABLES ensures that they are in the binlog too. See
# comment above.
FLUSH TABLES;
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
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