Hi Mark,
> Where is the claim about transactions being visible before crash-safety in his thesis? I didn't find it via a quick
searchof the pdf.
I feel like I've waded into something here without all of the context, but Kevin is referring to some text in section
4.4on page 63 of my thesis:
"InnoDB holds a transaction’s locks until the point in transaction commit just before the write-ahead log is flushed.
Inother words, locks are released and changes become visible before log records are guaranteed to be on stable storage.
Thisearly release of locks creates a window of vulnerability in which a query could commit after seeing data values
thatwould be lost after a crash. For short transactions that perform no other I/O, this optimization in InnoDB reduces
theduration for which locks are held by 1-2 orders of magnitude. The reasoning given in the InnoDB source code for this
designis that as the log is flushed in order, any subsequent update based on the not-yet-flushed data could not be
flushedbefore the data it depends on. However, this reasoning does not apply to queries, which can read data that has
notyet been made durable. There are various configuration parameters that can reduce the cost of flushing the log,
includinggroup commit and skipping the flush entirely, so releasing locks early is an interesting design choice."
I do not know whether this is still true of InnoDB today.
Michael.