-
Type: Task
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Not Applicable
-
Storage Engines
-
RSS Sydney - 2024-07-09
-
Not Needed
Summary
mongod calls WT's session->drop during rollback-to-stable in the event that a partially-built index is discovered, in which case we need to re-build from scratch. To do this we perform untimestamped drop of the index, then recreate a new one with the same name.
This operation sometimes EBUSYs (see linked issue)
Asks
We'd like to understand more about why the EBUSY might occur at this point. Specifically:
- do `checkpoint_wait=true,lock_wait=true` help?
- does control reach `__wt_session_dhandle_try_writelock`?
- Would retrying be a viable fix here?
Links
- BF-34053 - the current issue
- BF-33055 - previous example of the above issue (from May)
SERVER-90075- speculative fix for the above issue
- related to
-
WT-10576 Return EBUSY on forced drop if there is an active transaction
- Closed