mirror of
https://github.com/MariaDB/server.git
synced 2025-01-24 07:44:22 +01:00
99f8d0a4a8
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'. mysql-test/extra/binlog_tests/binlog_insert_delayed.test: removing sleeps, syncronizing with system delayed thread per each statement, note that an insert statement is performed atomically including writing to binlog, so that concurrent selects are waiting. That's why the wait macro is safe. mysql-test/r/binlog_row_binlog.result: new result mysql-test/include/wait_until_rows_count.inc: macro implements waiting until a targeted table has a prescribed rows number. |
||
|---|---|---|
| .. | ||
| binlog.test | ||
| binlog_insert_delayed.test | ||
| blackhole.test | ||
| ctype_cp932.test | ||
| ctype_cp932_binlog.test | ||
| ctype_ucs_binlog.test | ||
| drop_temp_table.test | ||
| innodb_stat.test | ||
| insert_select-binlog.test | ||
| mix_innodb_myisam_binlog.test | ||