List:Commits« Previous MessageNext Message »
From:Dmitry Lenev Date:October 6 2010 7:00am
Subject:Re: bzr commit into mysql-5.5-runtime branch (jon.hauglid:3153)
View as plain text  
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
> revid:jon.hauglid@stripped
>  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/'
> --- a/storage/myisammrg/	2010-09-08 08:25:37 +0000
> +++ b/storage/myisammrg/	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. */
>      child_l->set_table_ref_id(mrg_child_def->get_child_table_ref_type(),
>                                mrg_child_def->get_child_def_version());
> -    /* 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,

Are you MySQL certified?
bzr commit into mysql-5.5-runtime branch (jon.hauglid:3153) Bug#57002Jon Olav Hauglid5 Oct
  • Re: bzr commit into mysql-5.5-runtime branch (jon.hauglid:3153)Bug#57002Dmitry Lenev6 Oct