List:Internals« Previous MessageNext Message »
From:Zardosht Kasheff Date:April 7 2011 4:30pm
Subject:Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?
View as plain text  
Another question.

How is this supposed to work with partitioning?

In fact, I do not see how NDB does it. In the call to handler::create
on a partitioned table, the input parameter name, which NDB passes to
readfrm, is not the name of the frm file. It is like the name of a
temporary file. The frm file is actually form->s->path.str. At least
this is the behavior I see in my engine. Then, when one runs "alter
table drop partition", I see no indication in the storage engine layer
that the frm file has changed. I see no call to
handler::create_handler_files. How would an engine that is being
partitioned become aware that the frm file has changed?

I was thinking of disabling this behavior I am trying to implement for
tables partitioned with our engine. Is there a way to find out if a
table is a partition? Would doing a strcmp(name, form->s->path.str)
work? Would checking form->part_info to see if it is NULL work?

Thanks
-Zardosht

On Thu, Apr 7, 2011 at 1:03 AM, Stewart Smith <stewart@stripped> wrote:
> On Wed, 06 Apr 2011 23:23:03 +0200, Jonas Oreland <jonas.oreland@stripped>
> wrote:
>> On 04/06/11 18:32, Zardosht Kasheff wrote:
>> > Hello all,
>> >
>> > Another question on this. Is the ONLY way an frm file may change is if
>> > an alter table occurs that is a metadata change only?
>>
>> if I understand your question correctly you should
>> look in handler.cc : update_frm_version
>> it makes a pwrite to frm-file, updating version...
>
> This is actually the MySQL Server version that last ran CHECK or REPAIR
> on the table (or that created it, but it's a different code path to
> update_frm_version). See also create_frm() in sql/table.cc
>
> This is different to the FRM file format version - which FRM_VER would
> lead you to believe is 6, INFORMATION_SCHEMA.TABLES column VERSION would
> lead you to think is 10 (it's NOT anything to do with how many times
> you've changed the table, it's the FRM file format version
> number-ish). The I_S column is really just the byte length number from
> the FRM file which is FRM_VER + 3 + test(create_info->varchar). I'm
> still not exactly sure what kind of sense this is meant to make.
>
> mysql_compare_tables in sql/sql_table.cc does some working out on if
> it's just a metadata only change. I'd have a bit of testing around this
> as I'm not sure the engines are properly informed... and I do casually
> wonder if there may be a NDB bug or two around this.
>
> Of course, correctly navigating around a lot of this code is roughly
> akin to drawing an accurate map of a large bowl of spaghetti.
>
> --
> 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