Michael, the session salvage, upgrade and verify methods currently hang if there's a cursor open, instead of returning EBUSY like session.drop and rename.
There's a test in __wt_session_lock_btree, that I was wondering about, don't we want an exclusive lock if it is a special command?
diff --git a/src/session/session_btree.c b/src/session/session_btree.c index 02c4496..3a0db7e 100644 --- a/src/session/session_btree.c +++ b/src/session/session_btree.c @@ -59,7 +59,7 @@ __wt_session_lock_btree(WT_SESSION_IMPL *session, uint32_t flags) * Special flags will cause the handle to be reopened, which * will get the necessary lock, so don't bother here. */ - if (LF_ISSET(WT_BTREE_LOCK_ONLY) || special_flags == 0) { + if (LF_ISSET(WT_BTREE_LOCK_ONLY) || special_flags != 0) { WT_RET(__wt_try_writelock(session, btree->rwlock)); F_SET(btree, WT_BTREE_EXCLUSIVE); }
Note, that also means bulk operations would return if there's a cursor open, which makes sense to me.
I smoke-tested that change and I know it's not correct, opening tables with indices fail, the change collides with this assertion in __wt_session_get_btree():
if ((ret = __wt_session_lock_btree(session, flags)) != WT_NOTFOUND) { WT_ASSERT(session, ret != 0 || LF_ISSET(WT_BTREE_EXCLUSIVE) == F_ISSET(session->btree, WT_BTREE_EXCLUSIVE)); return (ret); }