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

Dropping a just opened LSM tree isn't safe

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT2.8.0
    • Labels:
      None

      Description

      Drop currrently relies on getting access to an LSM tree that is not active. If drop is the first operation on a tree, it will open the tree with WT_LSM_TREE_ACTIVE set, which violates assumptions.

      If I add an assertion to LSM to verify the assumption, it fails when running a simple python test that does a drop on an existing table.

      Call stack:

      (gdb) where
      #0  0x00007f35cbe25a98 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
      #1  0x00007f35cbe2772a in __GI_abort () at abort.c:89
      #2  0x00007f35c49df071 in __wt_abort (session=0xb35d60) at ../src/os_posix/os_abort.c:25
      #3  0x00007f35c4a211b3 in __wt_assert (session=0xb35d60, error=0,
          file_name=0x7f35c4a48f7a "../src/lsm/lsm_tree.c", line_number=864, fmt=0x7f35c4a48f77 "%s")
          at ../src/support/err.c:470
      #4  0x00007f35c49d5a01 in __wt_lsm_tree_drop (session=0xb35d60, name=0x7f35bfe94894 "lsm:test", cfg=0x7ffc9dcbba50)
          at ../src/lsm/lsm_tree.c:864
      #5  0x00007f35c4a04d51 in __wt_schema_drop (session=0xb35d60, uri=0x7f35bfe94894 "lsm:test", cfg=0x7ffc9dcbba50)
          at ../src/schema/schema_drop.c:184
      #6  0x00007f35c4a174da in __wt_session_drop (session=0xb35d60, uri=0x7f35bfe94894 "lsm:test", cfg=0x7ffc9dcbba50)
          at ../src/session/session_api.c:733
      #7  0x00007f35c4a17722 in __session_drop (wt_session=0xb35d60, uri=0x7f35bfe94894 "lsm:test",
          config=0x7f35bfe94834 "force") at ../src/session/session_api.c:760
      #8  0x00007f35c4c9db00 in _wrap_Session_drop (self=<optimized out>, args=<optimized out>) at wiredtiger_wrap.c:6501
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alexander.gorrod Alexander Gorrod
                Reporter:
                alexander.gorrod Alexander Gorrod
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: