From: Kristian Nielsen Date: April 15 2012 8:17am Subject: Re: question on storage engines, two phase commits, and fsyncing on commit List-Archive: http://lists.mysql.com/internals/38502 Message-Id: <87obqt1k9v.fsf@frigg.knielsen-hq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sergei Golubchik writes: > On Apr 14, Zardosht Kasheff wrote: >> Storage engines that support two-phase commit implement the functions >> handlerton->prepare and handlerton->commit. Clearly, a storage engine >> must fsync its own log after handlerton->prepare so that if we crash, >> it may report the prepared transaction to MySQL via >> handlerton->recover. >> >> My question is this: Do we need to fsync our log after >> handlerton->commit, or can we somehow be guaranteed that if we do not >> fsync, upon a crash, MySQL will have enough information to call >> handlerton->commit_by_xid on what is a prepared transaction in our >> storage engine? > You're absolutely right! > Indeed, a storage engine is expected to sync both on prepare and on > commit. You understanding is correct. > > But we're going to weaken this requirement in MariaDB (not surprisingly > :). We've discussed the solution just about a month ago, and the > corresponding task is "In Progress". I'll check what's exactly going on Here is the task: https://mariadb.atlassian.net/browse/MDEV-181 The actual design is work-in-progress, and can/will be simplified a lot - but the basic idea should be there. Also see the comments on the new prepare_ordered() / commit_ordered() functions in handler.h. And the worklog: http://askmonty.org/worklog/Server-Sprint/?tid=116 - Kristian.