Arjen Lentz writes:

As a sideline of this, we need a test that verifies that the two-phase commit process actually works.

This could be done by starting a transaction, doing some write in both XtraDB and PBXT, but set things up in such a way that a commit will fail on one - perhaps Paul can provide a good idea for this - then the testcase can simply check the values in the XtraDB and PBXT tables afterwards to assess what happened.

Yes. This is simple enough to do with DBUG. Just insert code that makes each engine fail in their prepare() when the appropriate DBUG flag is set. Another test we need is to have similar code to crash the server at the same points. Then on server restart check that the other engine does rollback.

This test is as important as the above crash, because multi-engine transactions are something people will be using and thus relying on correctly working, however the code inside MySQL core that handles it

Actually, I think it is best to avoid multi-engine transactions. There are a number of subtle points that complicate things, both with current code and in principle. (For example current code has no protection against another thransaction seeing a transient state with one engine committed and another not, even using START TRANSACTION WITH CONSISTENT SNAPSHOT. And there are fundamentally unsolvable problems with transactions that span both MVCC- and lock-based engines). There is a cool-ness factor to having multi-engine transaction working, of course (it would be very interesting to hear real-world use cases btw). But I agree that basic stuff should work, like the tests you suggested.

is wholly untested. The test is of course also important to guard against regressions when other bugs around this code get found & fixed over time.

Wholly untested with binlog disabled, yes. With binlog enabled, there are already two XA engines in play (innodb + binlog), so that part is better tested. - Kristian.