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