From: Zardosht Kasheff Date: March 30 2011 12:11pm Subject: Re: storage engine access to serialized version of a TABLE or TABLE_SHARE? List-Archive: http://lists.mysql.com/internals/38277 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Hello all, Thanks again for the feedback. My plan is not to silently overwrite things. When handler::open gets called, if I notice that the frm file generated from the TABLE* parameter is different than the frm file I have stored on disk, I will return an error. What I wanted to confirm is that if by some mechanism, I replace the contents of the bad frm file with what I have saved (perhaps by some table discovery method?), then the next time the table is opened, everything should work right. -Zardosht On Wed, Mar 30, 2011 at 3:21 AM, Stewart Smith wrote: > On Tue, 29 Mar 2011 21:36:22 -0400, Zardosht Kasheff wrote: >> I want to make sure that my understanding is correct. Looking at NDB, >> it seems that they use the functions readfrm() and packfrm() to save >> the frm file. readfrm() seems get the contents uncompressed, and >> packfrm() compresses them. > > correct. in NDB we stored the FRM in a compressed format as we keep them > all in the (in memory) NDB data dictionary. > > There's no requirement to compress them, it just saved valuable memory > for us (I previously worked on NDB). > >> Suppose I want to just save the raw uncompressed bytes that make up >> the file. I think I can just use the function readfrm() to get the >> data. And, if some crash caused the frm file and my saved version to >> get out of sync, I can just generate a new frm file by saving the data >> that readfrm() retrieved into a new frm file. > > yes.... but what you really want to do is pass an error back to the > server like NDB does, if you just silently overwrite things and keep > going, there is likely to be (as Sergei says) very odd behaviour from > the upper MySQL layers. > > MySQL keeps a cache of the table definition in data structures so that > it doesn't have to parse the FRM very often (as that is relatively > expensive). > > -- > Stewart Smith >