From: Stewart Smith Date: April 7 2011 5:03am Subject: Re: storage engine access to serialized version of a TABLE or TABLE_SHARE? List-Archive: http://lists.mysql.com/internals/38290 Message-Id: <87y63mtzzb.fsf@flamingspork.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Wed, 06 Apr 2011 23:23:03 +0200, Jonas Oreland 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