Re: Independent comparison of PostgreSQL and MySQL
От | Michael Cahill |
---|---|
Тема | Re: Independent comparison of PostgreSQL and MySQL |
Дата | |
Msg-id | B060D9E4-3405-4291-A643-AA27820B90F8@wiredtiger.com обсуждение исходный текст |
Ответ на | Re: Independent comparison of PostgreSQL and MySQL (MARK CALLAGHAN <mdcallag@gmail.com>) |
Список | 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 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.
В списке pgsql-advocacy по дате отправления: