Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-43018

Formalize contract for safely accessing the catalog

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.3.1, 4.2.3
    • Affects Version/s: 4.2.0
    • Component/s: Replication, Storage
    • None
    • Fully Compatible
    • ALL
    • v4.2
    • Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07, Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18
    • 12

      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.

            Assignee:
            suganthi.mani@mongodb.com Suganthi Mani
            Reporter:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: