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

Catalog change to declare an index as multikey must be timestamped.

    • Fully Compatible
    • Repl 2018-01-15, Repl 2018-01-29, Repl 2018-02-12

      There are two cases to resolve. The first is easier. The second is a little trickier:

      When a document is inserted/updated into a collection that can require multiple entries in an index (e.g: the value of an indexed field is an array), the index's "multikey" field must be set to true.

      This update is currently done as a side-transaction to avoid write conflicts. Being a side-transaction throws away the ability to inherit a timestamp from the insert/update request.

      Proposed solutions can be classified as:

      1. Remove the side transaction. Solutions here have varying degrees of effort to still allow for serialization of updates to the document to prevent a worst case scenario where progress slows down (stops?)
      2. Assign a timestamp to the write that is at least as early as any updates that are part of the request requiring this update.
        • A bit more clever, introduce an error case when inserts require the multikey field to be changed to true. Top-level handlers should translate this error to setting multikey to true (in a "before?-transaction") followed by performing the insert. An explicit timestamp would still need to be chosen, but there might be less plumbing required to make the timestamp and transaction meet.

            Assignee:
            judah.schvimer@mongodb.com Judah Schvimer
            Reporter:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: