[SERVER-80727] Data race for inReplicationRecovery between recovery thread and index builds Created: 05/Sep/23 Updated: 09/Nov/23 Resolved: 09/Nov/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yujin Kang Park | Assignee: | Yujin Kang Park |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Execution EMEA Team 2023-09-18, Execution EMEA Team 2023-10-02, CAR Team 2023-11-13 | ||||
| Participants: | |||||
| Linked BF Score: | 5 | ||||
| Description |
|
Index builds use temporary record stores, which are not supposed to track size adjustments (and check inReplicationRecovery). On resume, the temporary record stores are opened using the regular record store code path, causing them to track size adjustments. inReplicationRecovery is set to true in recoverFromOplog, but concurrent checks for inReplicationRecovery can be running before the recovery thread reaches that point. This is the case for index builds, which are restarted/resumed earlier in the recovery process, when rolling back the storage engine to the stable timestamp and re-opening the catalog (_recoverToStableTimestamp). This creates a race between an index build thread checking inReplicationRecovery and the rollback thread setting the flag. |
| Comments |
| Comment by Githook User [ 09/Nov/23 ] |
|
Author: {'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}Message: |