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

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



    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.7.2
    • Storage
    • 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.


        Issue Links



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