Hello Jon Olav!
* Jon Olav Hauglid <jon.hauglid@stripped> [10/10/05 14:34]:
> #At file:///export/home/x/mysql-5.5-runtime-bug57002/ based on
> 3153 Jon Olav Hauglid 2010-10-05
> Bug #57002 Assert in upgrade_shared_lock_to_exclusive()
> for ALTER TABLE + MERGE tables
> === modified file 'storage/myisammrg/ha_myisammrg.cc'
> --- a/storage/myisammrg/ha_myisammrg.cc 2010-09-08 08:25:37 +0000
> +++ b/storage/myisammrg/ha_myisammrg.cc 2010-10-05 10:25:30 +0000
> @@ -478,8 +478,9 @@ int ha_myisammrg::add_children_list(void
> /* Set the expected table version, to not cause spurious re-prepare. */
> - /* Use the same metadata lock type for children. */
> - child_l->mdl_request.set_type(parent_l->mdl_request.type);
> + if (! thd->locked_tables_mode &&
> + parent_l->mdl_request.type == MDL_SHARED_NO_WRITE)
> + child_l->mdl_request.set_type(MDL_SHARED_NO_WRITE);
> /* Link TABLE_LIST object into the children list. */
> if (this->children_last_l)
> child_l->prev_global= this->children_last_l;
I think we need to add comment describing why we need such
a special handling of MDL_SHARED_NO_WRITE. Something like:
For statements which acquire SNW metadata lock on parent table and
then later try to upgrade it to X lock (e.g. for ALTER TABLE) SNW
lock should be also taken on underlying tables.
Otherwise we end up in situation when thread trying to upgrade SNW
to X lock on parent also holds SR metadata lock and read thr_lock.c
lock on child. As result another thread might be blocked on thr_lock.c
lock for child after successfully acquiring SR or SW metadata lock on
it. If at the same time this second thread has shared metadata lock on
parent table or there is some other thread which has shared metadata
lock on parent and is waiting for this second thread we get a deadlock.
This deadlock cannot be properly detected by MDL subsystem as part of
waiting happens within thr_lock.c.
By taking SNW locks on child tables we ensure that any thread which
waits for thread doing SNW -> X upgrade does this within MDL subsystem
and thus potential deadlocks are exposed to deadlock detector.
We don't do the same thing for SNRW locks as this would allow
DDL on implicitly locked underlying tables of MERGE table.
(As always adjustments to the text are welcome! :))
Otherwise I am OK with this patch and think that it can be pushed
after addressing the above point.
Dmitry Lenev, Software Developer
Oracle Development SPB/MySQL, www.mysql.com
Are you MySQL certified? http://www.mysql.com/certification