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

Add readonly flag to wt utility

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.1, 4.3.1, WT10.0.0
    • Affects Version/s: None
    • Component/s: None
    • None
    • 3
    • Storage Engines 2019-09-09, Storage Engines 2019-09-23

      In WT-4535 certain commands inside of the wt utility command started specifying read-only mode always. There has been a lot of fallout from that change in WT-5100 and WT-5102. That fallout comes in the form of an assertion failure and dropping core.

      [1567617703:17577][99927:0x700004f89000], wt, statlog-server: __wt_open, 247: lock_file || !LF_ISSET(WT_FS_OPEN_CREATE)
      [1567617703:17655][99927:0x700004f89000], wt, statlog-server: __wt_abort, 28: aborting WiredTiger library
      

      Today I did a simple run of:

      % ./test_timestamp_abort -T 5 -t 5
      % ../../wt -h WT_TEST.timestamp-abort printlog
      

      and got the above failure. That is on a cleanly shutdown database that did not require recovery either. The above set of commands are a common usage for me.

      I think we need to revisit the changes from WT-4535.

      • Normal usage should not drop core.
      • Normal usage should work.
      • Normal usage should not require any manual file manipulation nor intermediary steps.
      • Normal usage should not require any knowledge of how the database was created by some program.
      • Read-only should be an explicit request, not something assumed under the covers.
      • There are too many implicit things that happen under the covers (like stats, log files, basecfg, etc) for the wt command to assume read-only is always correct.

            Assignee:
            luke.pearson@mongodb.com Luke Pearson
            Reporter:
            sue.loverso@mongodb.com Susan LoVerso
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: