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

wiredtiger_open with a corrupted meta file should always return WT_TRY_SALVAGE

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT10.0.0, 4.2.2, 4.3.3
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Execution Team 2019-11-18
    • v4.2
    • Not Needed

      This a followup to WT-4344. After stopping the application, and then damaging, removing or truncating any of the "meta" files, a wiredtiger_open call without any salvage option should either complete normally, or return WT_TRY_SALVAGE. Basically, we should return WT_TRY_SALVAGE in all cases where an open is failing (for other than "permission denied", or "already locked"). There are probably fewer cases where salvage is not appropriate, than cases where it is.

      For meta files, we are talking about any WiredTiger-owned file in the home directory that is not a log files or user table file. So: WiredTiger, WiredTiger.basecfg, WiredTiger.turtle, WiredTiger.wt, WiredTigerLAS.wt.

      There are currently a variety of behaviors when we damage these files, we sometimes see "unknown configuration key", an open failure call, or a WT_NOTFOUND on the turtle file, all leading to a wiredtiger_open failure. As much as possible, these cases should finally result in a WT_TRY_SALVAGE error so the caller knows what action to recommend, or try next.  The test_txn19.py changes as a part of WT-4344 test these cases, but leaves lax the various reported failure conditions.

            Assignee:
            gregory.wlodarek@mongodb.com Gregory Wlodarek
            Reporter:
            donald.anderson@mongodb.com Donald Anderson
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: