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

reIndex should take a Global exclusive lock instead of just Database

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.0-rc6, 4.1.1
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Minor Change
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Storage NYC 2018-06-18
    • Linked BF Score:
      72

      Description

      reIndex does writes (both timestamped and untimestamped) but it does not acquire new optimes for such writes; it just piggybacks on whatever the current logical clock time is.
      This renders the minimumVisibleSnapshot mechanism somewhat ineffective, since that requires new timestamps to be created for each write that is to be protected.
      Because multi-document transactions establish a snapshot protected only by a Global lock and not a Database lock, it is possible to establish a snapshot in between a begin-index-build write and a commit-index-build write performed by a reIndex. Because the snapshot read time can be outside the minimumVisibleSnapshot time on the collection, such a snapshot can then see that the in-memory catalog shows the index as being ready, even though the storage engine catalog will show the index as being not-ready. This discrepancy can cause problems, including invariant failures.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              milkie Eric Milkie
              Reporter:
              milkie Eric Milkie
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: