When debugging SERVER-21833:

test_compact02.py creates a file, removes some rows, reopens the database and compacts the file.

Previously, the reopen call was a checkpoint, and when it was a checkpoint it failed most of the time on tinderbox and some of the time on AWS/OS X boxes, compaction never happened.

I first thought it was the existence of dirty pages in the cache, but that's not correct, the checkpoint should have "cleaned" all the pages in the cache.

There's potentially conflict with cache eviction over the pages being written, but I don't think that's it either.

Or maybe an already opened handle is preventing the compact operation from switching to a first-fit block allocation algorithm, but a quick test didn't turn up anything there, either.

If I open the compact handle with WT_DHANDLE_EXCLUSIVE instead, the problem appears to go away, so I think the problem has something to do with an already open handle preventing the checkpoint blocks at the end of the file from being discarded.

I need to figure this out at some point; even if everything is working correctly, we should change compaction to attempt to acquire the handle exclusively. It can proceed if that acquisition fails, but it's reasonable to try it first if it makes this much of a difference.