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

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: 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
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      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 (Inactive)
            Reporter:
            Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: