FWIW, I noticed in reviewing WT-1056 that we use next transaction ID + 1 as our best estimate of the "oldest running transaction". That isn't a very good estimate, and may keep pages pinned for longer than necessary.

In particular, in the unlikely event that an application were to switch to read-only mode right at the point were we split a page, it's possible that the chosen ID would never become globally visible, because it never gets incremented. This could keep those pages from being evicted.

OTOH, I tried to figure out another ID that is definitely safe. My original idea was to use the current thread's snap_min, but it is possible things have moved on since we calculated that. We don't track the oldest running transaction precisely, and an out-of-date value isn't helpful here.

One possibility would be to use the session's own transaction ID (if it has one), or to allocate a new transaction ID and use that (to avoid the read-only case mentioned above).