The problem was due to InnoDB purge thread which would not treat lock types on WSREP_BF correctly when inheriting locks.
In the fix, InnoDB lock manager was refactored to not use WSREP_BF lock mode anymore. Locking priority is implemented by checking running transactions BF state at the time of each lock conflict. We will need another round of refactoring, to not access mysql THD structure for each lock conflict, transaction state can be held in InnoDB trx.
Fix was pushed into wsrep-5.5, in revision: http:// bazaar. launchpad. net/~codership/ codership- mysql/wsrep- 5.5/revision/ 3934
The problem was due to InnoDB purge thread which would not treat lock types on WSREP_BF correctly when inheriting locks.
In the fix, InnoDB lock manager was refactored to not use WSREP_BF lock mode anymore. Locking priority is implemented by checking running transactions BF state at the time of each lock conflict. We will need another round of refactoring, to not access mysql THD structure for each lock conflict, transaction state can be held in InnoDB trx.