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

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: WT3.0.0
    • Fix Version/s: 3.6.9, 4.0.2, 4.1.2, WT3.2.0
    • Component/s: None
    • Labels:
      None
    • Epic Link:
    • Sprint:
      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

              Assignee:
              donald.anderson Donald Anderson
              Reporter:
              donald.anderson Donald Anderson
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: