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

__wt_conn_btree_apply_single and bulk loads.

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

      @michaelcahill, glad we decided to go back and look at this one.

      What's happening is this:

      1. We open a handle for bulk loading a file, setting btree->flags == WT_BTREE_BULK, so there's an entry in the connection cache file:__wt (checkpoint == NULL)

      2. We start a checkpoint, and *checkpoint_worker calls *wt_session_lock_checkpoint to lock the checkpoint handles, creating a second handle in the connection cache, file:__wt (checkpoint == WiredTigerCheckpoint.2).
      3. The checkpoint then calls *wt_conn_btree_apply, which finds the bulk-load handle file:*wt and can't access it, so *wt_conn_btree_apply calls *wt_conn_btree_apply_single, which looks for a "matching" URI.

      The matching URI it finds is the checkpoint handle, and the diagnostic code I added gets unhappy, because we have a "matching" handle that isn't a bulk-loaded handle and so it shouldn't have returned EBUSY in __wt_conn_btree_apply.

      I'm going to look at a couple of things:

      • Should we be ignoring handles for checkpoint files in __wt_conn_btree_apply?
      • Should we be matching on both the URI and the checkpoint name in __wt_conn_btree_apply_single?
      • Should the checkpoint code lock checkpoint handles we're creating?

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

              Created:
              Updated:
              Resolved: