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

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

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.9, 4.0.2, 4.1.2, WT3.2.0
    • Affects Version/s: WT3.0.0
    • Component/s: None
    • None
    • Storage Non-NYC 2018-07-16, Storage Engines 2018-07-30

      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.

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