WT would mark tables that are individually checkpoint'ed, separately from the database-wide checkpoint, such that a MongoDB request for a WiredTigerCheckpoint cursor against such an individually checkpoint'ed table would return an error. Every time a new WiredTigerCheckpoint checkpoint is taken, the table markers would be cleared.

Motivation:

For MongoDB's background validation cmd, we need a window of time where we can open cursors against all the relevant WT tables at once in the same checkpoint with a consistent view across collection and index tables. Then those cursors must not see anything new (typical cursor behavior). New checkpoints are fine, so long as the existing cursor views are undisturbed.

Bulk loads in WT can supposedly cause the targeted table to be individually checkpoint'ed; and Geert expects calling verify on a WT table can similarly provoke an individual table checkpoint'ed as well.

Rather than MongoDB specially keeping track of which tables are safe for the MongoDB validate cmd to look at, and resetting that list every time MongoDB calls WT for a checkpoint(), it seems cleaner (and more future safe) for WT to track which tables are no longer part of the consistent database-wide checkpoint view, and then return an error for any table access that is not part of the current consistent database-wide checkpoint view.

We do not currently see any need for MongoDB to ever override the proposed error behavior, so no additional view option to see an individually checkpoint'ed table is necessary. It seems reasonable for MongoDB to only ever want to see a consistent database-wide checkpoint view.