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

wiredtiger_open with a corrupted meta file should always return WT_TRY_SALVAGE



    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2, 4.2.2, 4.3.3
    • Component/s: None
    • Labels:
    • Sprint:
      Execution Team 2019-11-18
    • Backport Requested:
    • Downstream Team Attention:
      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.


          Issue Links



              • Assignee:
                gregory.wlodarek Gregory Wlodarek
                donald.anderson Donald Anderson
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: