The MongoDB catalog is currently compromised of two layers:

• An in-memory layer that represents "now"
• A durable layer which is transparently (to the storage engine) backed in the same datastore as all of the other data.

A single read of the catalog can be serviced by both layers and the durable layer is typically keyed on the collection namespace. Thus allowing changes to the in-memory version while holding a transaction/snapshot open on the durable layer requires concurrency control to prevent wires getting crossed.

The proposed contract for catalog reads safe:

• Reading with a timestamped (storage) transaction is always safe.
• Reading without a timestamped transaction requires either:
  • Acquiring locks on all relevant collections prior to acquiring a snapshot for a catalog read.
  • Computing/Setting a "catalog conflicting timestamp". The snapshot acquired must include all writes up to this time. It's permissible for the snapshot to include additional writes at a later timestamp.

In cases where a read timestamp is not specified, the "catalog conflicting timestamp" must be substituted for comparison against "minimum visible timestamps" (1, 2 and 3).

This "catalog conflicting timestamp" mechanism can be removed when a versioned catalog backed by the durable catalog is in place.

A sample, incomplete patch is attached.