From: Stewart Smith Date: March 30 2011 7:14am Subject: Re: storage engine access to serialized version of a TABLE or TABLE_SHARE? List-Archive: http://lists.mysql.com/internals/38275 Message-Id: <874o6loza5.fsf@flamingspork.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Tue, 29 Mar 2011 07:59:15 -0400, Zardosht Kasheff wrote: > On Tue, Mar 29, 2011 at 7:58 AM, Zardosht Kasheff wrote: > > Hello Dmitry and Sergei, > > > > I will look to see how NDB grabs the frm file. The reason I want it is > > that i do not want to risk the frm file and table going out of sync. > > It is not a problem now, but I am trying to be proactive. You're mostly screwed in getting this perfect in MySQL - we still get issues every so often with NDB. The solution there is to remove the FRM files from disk and let table discovery fix it up. In NDB we also have checks that notice when they're out of sync and then try and pull the table definition down so that on the next access everything works. > > Internally, our storage engine is fully transactional. So, what I want > > to do is save the new frm file for the altered table in some metadata > > dictionary with the same transaction that performs data operations for > > the alter (e.g. adds a column to every row of the table). This way, if > > there is a crash, our engine can produce what the frm file should be > > and the user can recover to a well known state. Right now, we just > > cross our fingers and hope the frm file is in sync with the data in > > the tables. NDB is certainly what to look at here. It's as close as you can reasonbly get in the MySQL code base to getting this right. If you do a Drizzle port, it is possible to do exactly what you describe - and you never need to store the table definitions on disk if you don't want to - it's just an API and a data structure that your engine needs to give the server, you could completely construct it out of your own data dictionary, fairly easily too. -- Stewart Smith