Comment 9 for bug 721611

Baron,

>>>>> INNODB_AUTO_LRU_DUMP
>
> I think we should consider the following candidate:
> innodb_buffer_pool_restore_at_startup
> This seems best to me because:
> - Although the file contains the space_id and page_no pairs, the
> buffer pool is what is restored.
> - Although the feature both saves the pairs and restores the buffer
> pool, the important part is restoring. (Saving the pairs is useless
> without the restore.) And naming with both "save" and "restore" is
> too long and awkward.

Hmm... I may have to compromise....

>
>>>>> INNODB_EXPAND_IMPORT
>
> Maybe we can use innodb_import_table_(rewrite|convert)_identifiers ?

Yes, it seems more clear than innodb_expand_import.
But... in more concretely,
export is done by xtrabackup
XtraDB can import it by this option.

I have came to...
It may be better to describe based on the usage than describe behavior as it is.

How about like the direction like
"innodb_import_table_from_xtrabackup" ?

>>>>> INNODB_PASS_CORRUPT_TABLE
>> can we named using opposite and negative words like
>> "force", "ignore" or something?
>> (like same image for force_recovery. And it is more expandable in the future. e.g. add leveling)
>> and default is 0 and 0 means abort when meet corruption.
>
> Maybe innodb_permit_corrupt_table=<level> is a good name?
>

"permit" seems little strange for me.

What permitted is...
"continue to work"
not
"corrupt table"

The corrupt table is marked as "corrupt" and reply to mysqld "corrupted" always.
not permitted, I think.