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

Do not enforce DataCorruptionDetected assertion when ignoring prepare conflicts

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.4
    • Sprint:
      Execution Team 2020-11-16, Execution Team 2020-11-30
    • Linked BF Score:
      34

      Description

      Snapshot isolation cannot be guaranteed for operations that ignore prepare conflicts. This means that two reads of the same record in the same snapshot can return different results. In practice, the assertion added by SERVER-40620 fails if an index points to a non-existent record. This may return false positives if a record is fetched in the collection after a prepared transaction that deletes that record commits.

      We cannot enforce the DataCorruptionDetected assertion if we are also ignoring prepare conflicts, or we will continue to get false positives.

      Original description:

      SERVER-37364 made the transaction coordinator return the decision as soon as the decision is persisted. As a result, the client is no longer guaranteed to see the effects of the transaction immediately after the commitTransaction returns. Based on this evergreen patch, a find command that is run immediately after an update shard key operation (but before the transaction finishes committing in the background) can fail with DataCorruptionDetected error (added in SERVER-40620).

        Attachments

          Activity

            People

            Assignee:
            louis.williams Louis Williams
            Reporter:
            cheahuychou.mao Cheahuychou Mao
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: