From Keith:

The second thing I wanted to talk to you about is that I think splits are "done" for v1, that is, I think the eviction + reconciliation architecture is sufficient for V1 release. And, I think it needs some fairly serious architectural review to catch any huge mistake I've made.

I think you can ignore page formats – they're not done, and will change a lot – but the way we're handling the in-memory pages needs to be thought about.

The tricky part that I am almost 100% sure works is the split code. Basically, when a page splits (or is emptied), it gets flagged as "merge with the parent" plus "logically evicted". Parents can be evicted if they have no subtrees, that is, if every possible child is either on-disk, or flagged as "logically evicted". The thing I think is OK is what happens if those pages are visited, and further split, or whatever. There's no reason that a page created during a split cannot be itself split and so on and so forth. It's pretty unlikely, but logically possible.

The places to look at btree/bt_evict.c (how it selects a page for eviction and decides a page can be evicted); bt_reconcile.c (ignore the page format stuff which is 90% of the code, and think about what happens when a page splits), and the combination of btree/bt_read.c, btree/bt_page.c and support/hazard.c, which decides when a page can be accessed by a reading/writing thread.