michael.cahill, I've been staring at the code that checks WT_PM_REC_MULTIBLOCK in __wt_page_can_split and __wt_page_can_evict, and I'm unclear on a couple of things.

First, it seems to me we're safe with respect to in-memory splits of pages where WT_PM_REC_MULTIBLOCK is set: the in-memory split of the parent page acquires the parent/internal page's WT_PAGE_RECONCILIATION lock, which will block out checkpoint's reconciliation of the page. However, we're potentially exercising a complicated error path when the split collides with the checkpointing thread and the split unrolls itself: we might want to make sure we're testing that error path more than casually, or alternatively, acquire the parent's reconciliation lock earlier, before we're so deeply committed.

Second, I don't think we're safe with respect to eviction of any page that will update an internal page, during a checkpoint (and that's any page where any WT_PAGE_MODIFY.flag value is set, not just WT_PM_REC_MULTIBLOCK. Here's the scenario:

1. Start a checkpoint,
2. The checkpoint reconciles an internal page, and finds child page X, reads WT_REF.state == WT_REF_MEM and WT_PAGE_MODIFY.flags == WT_PM_REC_REPLACE, then sleeps.
3. Then evict page X because it's clean and WT_PM_REC_MULTIBLOCK isn't set. That ends up in __evict_page_dirty_update, where we replace WT_REF.addr with WT_PAGE_MODIFY.mod_replace, and clear that value.
4. The checkpoint then wakes up, and based on its reading of WT_PAGE_MODIFY.flags, reads WT_PAGE_MODIFY.mod_replace.

Hopefully I'm just missing something...