[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:
Depends
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: SERVER-80727 Fix temporary record store reopened for resume tracks size adjustment
Branch: master
https://github.com/mongodb/mongo/commit/60c0d5099290d7578727ea901d72b303e85a0992

Generated at Thu Feb 08 06:44:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.