Hello all,
I would like to resurrect this thread, because according to a comment
here, http://bugs.mysql.com/bug.php?id=42230, this patch is not
sufficient.
To recap, the problem is the following: for storage engines that do
NOT implement handler::add_index, users can query a table while
another thread is adding an index. For storage engines that DO
implement handler::add_index, queries block until index creation
completes. This is a bug I would very much like to fix.
I would like to understand the issues present and why the fix is not
sufficient. Here are relevant comments from the bug report:
- "fast" alter table code was re-shuffled and lost it's locking
context. But it still
works, because of fix for BUG#24395;
- mdl was introduced and we're further loosing add/drop index locking context;
Here are questions I have:
In 5.1, why is this fix not sufficient?
What is the "locking context" that is lost? Why is
open_n_lock_single_table not sufficient for locking?
How does the newly introduced metadata lock affect this problem?
Thanks
-Zardosht
On Fri, Jul 23, 2010 at 10:47 PM, Davi Arnaut <davi.arnaut@stripped> wrote:
> On 7/23/10 10:45 PM, Zardosht Kasheff wrote:
>>
>> Hello all,
>>
>> After some investigation, I think the attached patch solves the issue.
>> I am interested in hearing feedback on the patch.
>>
>
> How about:
>
> === modified file 'sql/sql_table.cc'
> --- sql/sql_table.cc (foo)
> +++ sql/sql_table.cc (bar)
> @@ -7280,7 +7280,7 @@ view_err:
>
> alter_info->keys_onoff,
>
> alter_info->error_if_not_empty);
> }
> - else
> + else if (alter_info->flags & ALTER_KEYS_ONOFF)
> {
> VOID(pthread_mutex_lock(&LOCK_open));
> wait_while_table_is_used(thd, table, HA_EXTRA_FORCE_REOPEN);
>
>
