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

cappedTruncateAfter must not set oldest timestamp during startup recovery when enableMajorityReadConcern=false

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.0.7, 4.1.7
    • Replication, Storage
    • None
    • Fully Compatible
    • ALL
    • v4.0
    • Hide

      Start up mongod with enableMajorityReadConcern:false and --replSet on the attached data files: repro.zip

      Show
      Start up mongod with enableMajorityReadConcern:false and --replSet on the attached data files:  repro.zip
    • Repl 2018-12-17
    • 33

    Description

      In cappedTruncateAfter, when majority read concern is disabled, we set the oldest timestamp to the truncate timestamp. This is incorrect when recovering from a stable timestamp at startup, since the truncate timestamp is the end of the oplog, and we will apply (and timestamp) writes from the recovery timestamp through the end of the oplog. This causes us to attempt to commit behind the oldest timestamp. We must not set the oldest timestamp to the truncate timestamp when recovering from a stable timestamp at startup.

      Attachments

        Activity

          People

            tess.avitabile@mongodb.com Tess Avitabile (Inactive)
            tess.avitabile@mongodb.com Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: