Actually, let me put this question another way. Suppose during a call
to handler::open, we return an error because the frm file generated
from the TABLE* parameter does not match the frm file we stored on
disk (due to some system crash at an inopportune time).
What, as a storage engine, can we do to get the user back to a well
known state where the frm file he is using matches what we have on
On Wed, Mar 30, 2011 at 8:11 AM, Zardosht Kasheff <zardosht@stripped> wrote:
> 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.
> On Wed, Mar 30, 2011 at 3:21 AM, Stewart Smith <stewart@stripped>
>> On Tue, 29 Mar 2011 21:36:22 -0400, Zardosht Kasheff <zardosht@stripped>
>>> 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
>> Stewart Smith