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.
- causes
-
WT-4196 Make log corruption checking work regardless of the machine byte order
-
- Closed
-
-
-
- Closed
-
- is related to
-
WT-3276 Add recover=salvage to recover from a corrupted log file
-
- Closed
-
- related to
-
WT-4186 Log recovery should detect and report corruption within log records
-
- Closed
-