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

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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.7, 4.1.7
    • Affects Version/s: None
    • Component/s: 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

      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.

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

              Created:
              Updated:
              Resolved: