maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Michael Widenius <michael.widenius@xxxxxxxxx> writes:

>> Yes, I'll prepare a patch for review. It's probably easier if I apply it
>> myself, as I want to do a minimal patch in 10.1 to get optimistic parallel
>> replication working with TokuDB; and a full patch in 10.2 which includes the
>> InnoDB simplifications.
>
> It would be great if you could do the above!

Ok, so I prepared patches for this:

  http://lists.askmonty.org/pipermail/commits/2016-September/009740.html
  http://lists.askmonty.org/pipermail/commits/2016-September/009741.html
  http://lists.askmonty.org/pipermail/commits/2016-September/009742.html

(Also available here: https://github.com/knielsen/server/commits/montyrpl)

I would like to push the first of these into 10.1, in order to fix
TokuDB. It has no functional changes for InnoDB/XtraDB. It introduces a
new slave background thread, Monty could you check that code and see if it
looks ok with respect to server shutdown and such?

The two other patches change InnoDB to use the async deadlock kill, and
remove the old locking hacks around innobase_kill_query() and such. In fact,
I still got locking violation assertions without these patches. These last
two patches should only go into 10.2. I think it will be good to get the
code cleaned up like this.

Serg, are you ok with making parallel replication deadlock kill happen
asynchronously? A couple years ago we discussed not doing this after review
(https://lists.launchpad.net/maria-developers/msg07483.html). This async
kill fixes locking problems in both TokuDB and (10.2) InnoDB. Also, the new
patch fixes the original problem; now there is no strange requirement for
storage engines to not report false positives. All a storage engine needs to
do is call thd_rpl_deadlock_check(waiting_thd, blocking_thd) to resolve
possible deadlocks in optimistic parallel replication. No tricky semantics.

> Feel free to push this into the bb-10.2-jan tree or into the 10.2 tree
> when Jan is ready with his merge!

Thanks. However, I see that Jan seems to be rebasing his bb-10.2-jan tree.
That doesn't work well with multiple developers pushing into a tree. Also,
these patches should not be folded into a large, anonymous "InnoDB 5.7
merge" commit message.

One option is that I could push the first patch into 10.1, and all three
patches into (main) 10.2. And then Jan can pick it up from main 10.2? Or do
you prefer me pushing them into a shared tree (bb-10.2-jan or whatever)?

 - Kristian.