mirror of
https://github.com/MariaDB/server.git
synced 2026-05-14 19:07:15 +02:00
18fa87d41a
The test case makes use of the fine DEBUG_SYNC facility. Furthermore, since it needs synchronization on internal threads (dump and SQL threads) the server code has DEBUG_SYNC commands internally deployed and activated through the DBUG_EXECUTE_IF macro. The internal DBUG_SYNC commands are then controlled from the test case through the DEBUG variable. There were three problems around the DEBUG + DEBUG_SYNC facility usage: 1. When signaling the SQL thread to continue, the test would reset immediately the DEBUG_SYNC variable. This could mean that the SQL thread might loose the signal and continue to wait forever; 2. A similar scenario was happening with the dump thread on the master. This thread was instructed to wait, and later it would be signaled to continue, but immediately after the DEBUG_SYNC would be reset. This could lead to the dump thread missing the signal and wait forever; 3. The test was not cleaning itself up with respect to the instrumentation of the dump thread. This would leave the conditional execution of an internal DEBUG_SYNC command active (through the usage of DBUG_EXECUTE_IF). We fix #1 and #2 by waiting for the threads to receive the signal and only then issue the reset. We fix #3 by reseting the DEBUG variable, thus deactivating the dump thread internal DEBUG_SYNC command. |
||
|---|---|---|
| .. | ||
| include | ||
| r | ||
| t | ||
| combinations | ||
| my.cnf | ||
| README | ||
| rpl_1slave_base.cnf | ||
How to run. =========== ./mysql-test-run.pl --suite=rpl --mysqld=--binlog-format=mixed