From 40d5f21679b8ac665e5eada69b77c8068627eb58 Mon Sep 17 00:00:00 2001 From: sumeerbhola Date: Mon, 18 Dec 2023 15:54:02 -0500 Subject: [PATCH] db: code comment about guaranteeing durability of initial state This is in response to the hazard raised in https://cockroachlabs.slack.com/archives/C0KB9Q03D/p1702923954950209?thread_ts=1702921711.638549&cid=C0KB9Q03D (internal link). --- open.go | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/open.go b/open.go index 3edad4cd87..33616d1aa2 100644 --- a/open.go +++ b/open.go @@ -705,10 +705,17 @@ func GetVersion(dir string, fs vfs.FS) (string, error) { return version, nil } -// replayWAL replays the edits in the specified log file. If the DB is in -// read only mode, then the WALs are replayed into memtables and not flushed. If -// the DB is not in read only mode, then the contents of the WAL are guaranteed -// to be flushed. +// replayWAL replays the edits in the specified log file. If the DB is in read +// only mode, then the WALs are replayed into memtables and not flushed. If +// the DB is not in read only mode, then the contents of the WAL are +// guaranteed to be flushed. Note that this flushing is very important for +// guaranteeing durability: the application may have had a number of pending +// fsyncs to the WAL before the process crashed, and those fsyncs may not have +// happened but the corresponding data may now be readable from the WAL (while +// sitting in write-back caches in the kernel or the storage device). By +// reading the WAL (including the non-fsynced data) and then flushing all +// these changes (flush does fsyncs), we are able to guarantee that the +// initial state of the DB is durable. // // The toFlush return value is a list of flushables associated with the WAL // being replayed which will be flushed. Once the version edit has been applied