maria-developers team mailing list archive

[Rich Prohaska <prohaska@xxxxxxxxxxx>]

Hello,
I have been debugging a deadlock problem in the 2PC logging code in
MySQL 5.6.7-rc.  Luckily, Sergei pointed me to a bug fix.  I
integrated this fix into MySQL 5.6.7, and with a couple of tweaks, the
deadlock problem is fixed.  I verified the fix with helgrind, since
helgrind reported a lock ordering violation in the original 5.6.7
code.

My tweaks are:

1. Move the mutex unlock to the right place in the
TC_LOG_MMAP::log_xid function.  WRT the main maria trunk, move line
7087 of log.c to after the break, since the code expects the page lock
to be held after the for loop.

2. helgrind reported a race on tc_log_cur_pages_used, so I used
statistic_increment on line 6983.  Also need to build with
SAFE_STATISTICS so that the statistics counters are atomically
modified.


---------- Forwarded message ----------
From: Sergei Golubchik <serg@xxxxxxxxxxxx>
Date: Thu, Oct 11, 2012 at 4:04 PM
Subject: Re: XA problems in mysql-5.6.7-rc
To: Rich Prohaska <prohaska@xxxxxxxxxxx>
Cc: internals@xxxxxxxxxxxxxxx


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:
http://bazaar.launchpad.net/~maria-captains/maria/5.1/revision/2881

> On Thu, Oct 11, 2012 at 3:54 PM, Sergei Golubchik <serg@xxxxxxxxxxxx> wrote:
> > 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.
> >
Regards,
Sergei