-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Schema Management
-
None
-
(copied to CRM)
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.