Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-4147

Log recovery should not ignore corruption outside of log records in a log file

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • WT3.0.0
    • 3.6.9, 4.0.2, 4.1.2, WT3.2.0
    • None
    • None
    • Storage Non-NYC 2018-07-16, Storage Engines 2018-07-30

    Description

      This is related to the work in WT-3276.  If corruption is added to the end of an otherwise clean log file that will be used in recovery (i.e. past the checkpoint), the corruption is ignored, recovery completes and all records are visible. This is the current behavior without any changes for WT-3276. Recovery should in fact fail, and salvage should truncate the log at the point of corruption.  In another case, when corruption occurs in a preallocated, but not yet used, part of a log file, it is not detected. It does result in a log file "hole", which sets the end point for recovery (no records past that point are used). But it is better for a real corruption to cause a visible failure.

      The work for WT-3276 contains a new test_txn19.py that has NOTE: comments to highlight the trouble areas.

      Attachments

        Issue Links

          Activity

            People

              donald.anderson@mongodb.com Donald Anderson
              donald.anderson@mongodb.com Donald Anderson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: