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); }