From: | Michael Cahill <mjc(at)wiredtiger(dot)com> |
---|---|
To: | MARK CALLAGHAN <mdcallag(at)gmail(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-advocacy(at)postgresql(dot)org" <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: Independent comparison of PostgreSQL and MySQL |
Date: | 2014-10-08 21:56:16 |
Message-ID: | B060D9E4-3405-4291-A643-AA27820B90F8@wiredtiger.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Hi Mark,
> Where is the claim about transactions being visible before crash-safety in his thesis? I didn't find it via a quick search of 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.4 on 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. In other words, locks are released and changes become visible before log records are guaranteed to be on stable storage. This early release of locks creates a window of vulnerability in which a query could commit after seeing data values that would be lost after a crash. For short transactions that perform no other I/O, this optimization in InnoDB reduces the duration for which locks are held by 1-2 orders of magnitude. The reasoning given in the InnoDB source code for this design is that as the log is flushed in order, any subsequent update based on the not-yet-flushed data could not be flushed before the data it depends on. However, this reasoning does not apply to queries, which can read data that has not yet been made durable. There are various configuration parameters that can reduce the cost of flushing the log, including group 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2014-10-08 22:33:01 | Re: Independent comparison of PostgreSQL and MySQL |
Previous Message | Adrian Klaver | 2014-10-08 21:51:32 | Re: Independent comparison of PostgreSQL and MySQL |