-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
There is a race between a reader accessing the local store copy of a tiered object at the same time that we decide to delete that file. We drop a local file in __tier_storage_remove_local():
if (__wt_handle_is_open(session, object)) { __wt_verbose(session, WT_VERB_TIERED, "REMOVE_LOCAL: %s in USE, queue again", object); WT_STAT_CONN_INCR(session, local_objects_inuse); /* COMMENT ELIDED */ WT_ASSERT(session, entry->tiered != NULL && entry->tiered->bstorage != NULL); entry->op_val = now + entry->tiered->bstorage->retain_secs; __wt_tiered_push_work(session, entry); } else { __wt_verbose(session, WT_VERB_TIERED, "REMOVE_LOCAL: actually remove %s", object); WT_STAT_CONN_INCR(session, local_objects_removed); WT_ERR(__wt_fs_remove(session, object, false));
There is nothing here that prevents a file handle from being re-opened after the check in __wt_handle_is_open() and before the file remove in __wt_fs_remove(). If I insert a sleep before the remove and add some read activity to test_tiered08 I can trigger this exact race.
- related to
-
WT-9823 Fix race between read and delete of WT_BLOCK in tiered storage
- Closed