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