List:Internals« Previous MessageNext Message »
From:Zardosht Kasheff Date:March 30 2011 1:54pm
Subject:Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?
View as plain text  
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
disk?

Thanks
-Zardosht

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.
>
> -Zardosht
>
> On Wed, Mar 30, 2011 at 3:21 AM, Stewart Smith <stewart@stripped>
> wrote:
>> On Tue, 29 Mar 2011 21:36:22 -0400, Zardosht Kasheff <zardosht@stripped>
> 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
>>
>
Thread
storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff29 Mar
  • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith29 Mar
  • Re: storage engine access to serialized version of a TABLE orTABLE_SHARE?Sergei Golubchik29 Mar
    • Re: storage engine access to serialized version of a TABLE orTABLE_SHARE?Dmitry Lenev29 Mar
    • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith30 Mar
Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff29 Mar
  • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff30 Mar
    • Re: storage engine access to serialized version of a TABLE orTABLE_SHARE?Sergei Golubchik30 Mar
    • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith30 Mar
      • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff30 Mar
        • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff30 Mar
          • Re: storage engine access to serialized version of a TABLE orTABLE_SHARE?Dmitry Lenev30 Mar
            • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff6 Apr
              • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Jonas Oreland6 Apr
                • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith7 Apr
                  • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Zardosht Kasheff7 Apr
                    • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith8 Apr
  • Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?Stewart Smith30 Mar