@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?