List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:January 13 2010 10:33am
Subject:Re: consequences of HTON_FLUSH_AFTER_RENAME
View as plain text  
Hi, Zardosht!

On Jan 12, Zardosht Kasheff wrote:
> Hello,
> I was wondering what the purpose of HTON_FLUSH_AFTER_RENAME is for
> handertons. It seems exposing this flag causes a call to "flush logs"
> after any "alter table". Is there any other purpose? The relevant code
> seems to be the following in
>   if (ha_check_storage_engine_flag(old_db_type, HTON_FLUSH_AFTER_RENAME))
>   {
>     /*
>       For the alter table to be properly flushed to the logs, we
>       have to open the new table.  If not, we get a problem on server
>       shutdown. But we do not need to attach MERGE children.
>     */
>     char path[FN_REFLEN];
>     TABLE *t_table;
>     build_table_filename(path, sizeof(path), new_db, table_name, "", 0);
>     t_table= open_temporary_table(thd, path, new_db, tmp_name, 0);
>     if (t_table)
>     {
>       intern_close_table(t_table);
>       my_free(t_table, MYF(0));
>     }
>     else
>       sql_print_warning("Could not open table %s.%s after rename\n",
>                         new_db,table_name);
>     ha_flush_logs(old_db_type);
>   }
> I see the last line calls "flush logs". I do not understand what the
> code before that does.

The original 2002 code looked like this:

    extern bool berkeley_flush_logs(void);
    if (old_db_type == DB_TYPE_BERKELEY_DB)

it's a workaround for some BDB quirk, and perhaps there could've been a
better fix anyway. Nobody but BDB ever needed that or used

Feel free to ignore this flag :)

consequences of HTON_FLUSH_AFTER_RENAMEZardosht Kasheff12 Jan
  • Re: consequences of HTON_FLUSH_AFTER_RENAMESergei Golubchik13 Jan