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

Improve "lock_wait" for operations that need exclusive access

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
      None
    • Case:

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            backlog-server-storage-engines Backlog - Storage Engines Team
            Reporter:
            michael.cahill Michael Cahill
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated: