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...
/Jonas
>
> -Zardosht
>
> On Wed, Mar 30, 2011 at 10:14 AM, Dmitry Lenev <Dmitry.Lenev@stripped>
> wrote:
>> Hello Zardosht!
>>
>> * Zardosht Kasheff <zardosht@stripped> [11/03/30 17:56]:
>>> 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?
>>
>> Here is what, AFAIK, NDB does.
>>
>> If during call to handler::ha_open() it is discovered that local version
>> of table/.FRM is out-of-date HA_ERR_TABLE_DEF_CHANGED error is returned.
>>
>> Upon getting such error code in server layer acquires appropriate locks,
>> invalidates corresponding entry in table definition cache and then
>> calls ha_create_table_from_engine() routine. The latter essentially calls
>> discover method of handlerton to get new version of .FRM and writes it
>> to disk.
>>
>> Hope this helps!
>>
>> --
>> Dmitry Lenev, Software Developer
>> Oracle Development SPB/MySQL, www.mysql.com
>>
>> Are you MySQL certified? http://www.mysql.com/certification
>>
>
