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

session.salvage, upgrade, verify hang if a cursor is open

    • Type: Icon: Task Task
    • Resolution: Done
    • WT1.3
    • Affects Version/s: None
    • Component/s: None

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

            Assignee:
            michael.cahill@mongodb.com Michael Cahill (Inactive)
            Reporter:
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: