List:Commits« Previous MessageNext Message »
From:Konstantin Osipov Date:March 2 2009 9:02pm
Subject:Re: bzr commit into mysql-6.0 branch (davi:2736) Bug#989 WL#4284
View as plain text  
* Davi Arnaut <Davi.Arnaut@stripped> [09/03/02 23:18]:
>  2736 Davi Arnaut	2009-03-02
>       Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
>       WL#4284: Transactional DDL locking
>       
>       This is a prerequisite patch: 
>       
>       These changes split lock requests from granted locks and manages
>       the memory and lifetime of granted locks within the MDL subsystem.

manage.

>       Furthermore, ticket locks can now be shared and therefore are used
>       to satisfy multiple lock requests, but only shared locks can be
>       recursive.

Maybe just "tickets", not ticket locks?

>       The problem is that the MDL subsystem morphs lock requests into
>       granted locks locks but does not manage the memory and lifetime
>       of lock requests, and hence, does not manage the memory of
>       granted locks either. This can be problematic because it puts the
>       burden of tracking references on the users of the subsystem and
>       it can't be easily done in transactional contexts where the locks
>       have to be kept around for the duration of a transaction.
>       
>       Another issue is that recursive locks (when the context trying to
>       acquire a lock already holds a lock on the same object) requires
>       that each time the lock is granted, a unique lock request/granted
>       lock structure structure must be kept around until the lock is
>       released. This can lead to memory leaks in transactional contexts
>       as locks taken during the transaction should only be released at
>       the end of the transaction. This also leads to unnecessary wake
>       ups (broadcasts) in the MDL subsystem if the context still holds
>       a equivalent of the lock being released.
>       
>       These issues are exacerbated due to the fact that WL#4284 low-level
>       design says that the implementation should "2) Store metadata locks
>       in transaction memory root, rather than statement memory root" but
>       this is not possible because a memory root, as implemented in mysys,
>       requires all objects allocated from it to be freed all at once.
>       
>       This patch combines review input and significant code contributions
>       from Konstantin Osipov (kostja) and Dmitri Lenev (dlenev).

I feel guilty knowing what's coming -- a bulk of renames that will
"mark" all the real changes that you're making with my name.
That's unfortunate, but merging it in in the opposite order would
make the process even more hard.

>      @ sql/mdl.h
>         Introduce a medata lock object key which is used  to uniquely
>         identify lock objects.
>         

metadata

>         Separate the structure used to represent pending lock requests
>         from the structure used to represent granted metadata locks.
>         
>         Rename functions used to manipulate locks requests in order to
>         have a more consistent function naming schema.
> === added file 'mysql-test/r/mdl_sync.result'

OK to push.



-- 
Thread
bzr commit into mysql-6.0 branch (davi:2736) Bug#989 WL#4284Davi Arnaut2 Mar
  • Re: bzr commit into mysql-6.0 branch (davi:2736) Bug#989 WL#4284Konstantin Osipov2 Mar