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

Improve "lock_wait" for operations that need exclusive access

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Schema Management
    • None

      Currently WT_SESSION::drop has an undocumented "lock_wait" config which controls whether the operation waits for high-level locks (such as the schema lock), or gives up immediately when they are unavailable. That undocumented flag is also unused: MongoDB now sets "force,checkpoint_wait=false" on all drops.

      Recent work in WT-3362 fixed a situation where even with those flags, drop could block while a checkpoint was active. At issue was the path to close all handles, which requires exclusive access, conflicting with a "lock-only" handle acquired by checkpoint.

      That change can cause EBUSY to be returned to other operations, such as WT_SESSION::verify, where previously it would have waited. That was noted in WT-3328.

      Consider implementing the "lock_wait" config of WT_SESSION::drop more thoroughly, with a WT_DHANDLE_LOCK_WAIT flag that control this behavior in the handle locking code rather than never waiting if WT_DHANDLE_LOCK_ONLY is set.

      Also consider adding "lock_wait" to more calls that need exclusive access (specifically WT_SESSION::verify, which can reasonably be called on a busy system.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            michael.cahill@mongodb.com Michael Cahill (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: