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.
- is caused by
-
WT-4535 Enhance wt command line utility to use read-only mode
- Closed