-
Notifications
You must be signed in to change notification settings - Fork 599
Open
Description
Consider the following code(in min-lsm/src/lsm_storage line714-line725):
if self.options.enable_wal {
std::fs::remove_file(self.path_of_wal(sst_id))?;
}
self.manifest
.as_ref()
.unwrap()
.add_record(&state_lock, ManifestRecord::Flush(sst_id))?;
self.sync_dir()?;
If the program loses power after the WAL deletion is completed, an error will occur during recovery, and we will be unable to restore the flushed memtable(which is not flush in record).
Therefore, in theory, we should reverse the order of these two.
However, I still have a concern regarding the reordering of code and instructions by the compiler and CPU. The write operation to the WAL (Write - Ahead Log) and the write operation to the manifest do not establish a happen - before relationship. In theory, their execution order can be swapped. If this happens, we may encounter the problem described in the above - mentioned code once again.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels