PS-9328: Fix sporadic rpl.rpl_backup_locked_by_applier test failures (8.0 version) #5424
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixed sporadic rpl.rpl_backup_locked_by_applier test failures which were caused by race condition in the test case.
Logic of the test assumes that conditional debug sync point in Rpl_applier_reader::purge_applied_logs(), which is used in this test, is supposed to be activated only once, when replication thread reaches it for the first time. The test case waits for this event, runs some commands to check that backup lock can't be taken, and then resumes execution of replication thread. After that it disables this conditional sync point.
However, if replication thread manages to reach this sync point for the second time, after test has resumed its execution and right before conditional sync point is disabled, it will wait on sync point until timeout is reached. As result the fact that debug sync point was reached but not handled will be detected during post test case check and cause its failure.
We fix this problem by moving disabling conditional sync point before we resume replication thread execution when sync point is reached for the first time.
The fix is applied to both 8.0 and 8.4 trees, since they are both affected.