On 10/22/10 11:40 AM, Zardosht Kasheff wrote:
> This is the bug #42230 that is filed.
>
[..]
>
> For engines that do not implement add_index, new_table is true and
> copy_data_between_tables is called, and wait_while_table_is_used is
This is a oversimplification, it does not help to understand the
problem. Anyway, who tells whether alter table needs a exclusive
metadata lock is the engine. Alter table uses the handler methods
check_if_incompatible_data and alter_table_flags to verify if the change
involves only metadata and and if online index operations are supported.
> not called. Queries may be run on the table while
> copy_data_between_tables is being run (a very very long operation).
If copy_data_between_tables is called, it means that the table data is
also going to be changed. If only metadata is being changed, there is no
need to copy over the the table data. For example, InnoDB's online index
add is a "metadata only" operation. Eventually, for both cases, a
exclusive metadata lock is always needed because the FRM needs to be
modified. If we are changing only metadata, this exclusive lock is taken
early as later the table will be renamed. If data is being changed, the
exclusive lock is delayed to after the table data has been copied.
> For engines that do implement add_index, new_table is false, the
> 'else' clause is run, and wait_while_table_is_used is called, blocking
> out all queries.
For your engine, data needs to be copied over to a new table on index
add? If not, its a metadata only change and exclusive lock is taken
because we are only going to modify the table metadata (frm).
The point is that it seems that this exclusive lock shouldn't be taken
so early (and this would be the regression introduced by Bug#24395) and
could be delayed to after add/drop_index. But Vojtovich claims that
there is code relying on this exclusive lock that is taken early. So we
need to wait him to identify which code is this.
Regards,
Davi
