When using TokuDB on MySQL 5.6.7-rc, we saw a 2PC deadlock caused by
locking flaws in the TC_LOG_MMAP::log_xid function. We merged a bug
fix from MariaDB 5.1 suggested by Sergei (see below) into MySQL 5.6.7,
and with a couple of tweaks, the failing test is now running.
The deadlock is a circular dependency among LOCK_sync, LOCK_active,
and the page lock. Here are some details.
thread 1 is blocked at line 2740 trying to get LOCK_active. it owns LOCK_sync.
thread 2 is blocked at line 2717 trying to get LOCK_sync. it owns the page lock.
thread 3 is blocked at line 2700 trying to get the page lock. it owns
On Thu, Oct 11, 2012 at 4:04 PM, Sergei Golubchik <serg@stripped> wrote:
> Hi, Rich!
> On Oct 11, Rich Prohaska wrote:
>> Hello Sergei,
>> Can you give me a pointer to a source files, or a source control changeset?
> This is the bug report: https://bugs.launchpad.net/maria/+bug/578117
> And this is the patch:
>> On Thu, Oct 11, 2012 at 3:54 PM, Sergei Golubchik <serg@stripped>
>> > On Oct 11, Rich Prohaska wrote:
>> >> Hello All,
>> >> TokuDB supports XA and runs in both MariaDB and MySQL. It works in
>> >> MariaDB without any patches. Unfortunately, there are several XA bugs
>> >> related to multiple XA storage engines in MySQL 5.6.7. It would be
>> >> great if these bugs were fixed in MySQL. One way to test these
>> >> changes is to include another example storage engine that supports XA.
>> >> This storage engine does not even need to work; it just needs to
>> >> export the prepare method in the handlerton interface.
>> >> There is a block of code in handler.cc surrounded by
>> >> WILL_BE_DELETED_LATER. If I disable the debug assert, what else do I
>> >> need to worry about?
>> > There is a possible deadlock in the MySQL XA code. I don't know how
>> > probable it is to get it in practice, we've found it with our mutex
>> > deadlock detector (MariaDB only). I had to rework XA code in MariaDB
>> > quite a bit to get rid of the deadlock.