Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-13284

Investigate why session->drop can EBUSY with `checkpoint_wait=true,lock_wait=true`

    • 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

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            nic.hollingum@mongodb.com Nic Hollingum
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: