First, handle close checkpoints files and so can discard underlying checkpoint blocks, it needs to check if a hot backup is in progress. Second, checkpoint needs to lock out the start of a hot backup once it checks the hot-backup flag, otherwise the hot backup could start while the checkpoint is still deleting file blocks.

Michael, this is a little more convoluted than I'd like, mostly because I didn't want to acquire any new locks in the handle close path.

The primary fix here is changing the checkpoint code to check the "hot backup in progress" flag when coming from the "handle close" path, otherwise we can delete checkpoints out from underneath a hot backup.

The other fix is avoiding a possible race – if we don't block starting a hot backup while completing the checkpoint, it seems to me a new hot backup could catch up with the checkpoint while it's still mucking with the file blocks, and no good would result from that.

I kept thinking I could do this work with the metadata_lock spinlock instead of creating a new lock, but it kept getting messy, so I created a new spinlock instead.

michaelcahill