diff options
author | Luis Soares <luis.soares@oracle.com> | 2014-06-26 12:54:27 +0100 |
---|---|---|
committer | Luis Soares <luis.soares@oracle.com> | 2014-06-26 12:54:27 +0100 |
commit | 5111df08146bcc9f233edada7eecdb1457b09d59 (patch) | |
tree | 2c01c7002d7b4abbdc86653e1fb71a2615ddb799 /client | |
parent | c6c2d43a602ecd56b1a025951cac6e299be504f5 (diff) | |
download | mariadb-git-5111df08146bcc9f233edada7eecdb1457b09d59.tar.gz |
BUG#13874553: rpl.rpl_stop_slave fails sporadically on pb2
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.
Diffstat (limited to 'client')
0 files changed, 0 insertions, 0 deletions