Michael Widenius <michael.widenius@gmail.com> 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.