After porting of twitter's timeout patch in https://blueprints.launchpad.net/percona-server/+spec/port-max-statement -time, it is possible for deadlock to occur when THD::awake is invoked from within innodb itself. One is the case presented here: https://bugs.launchpad.net/percona-xtradb-cluster/5.6/+bug/1233301 where the wsrep code calls THD::awake during a BF abort and deadlocks on lock_sys->mutex and trx->mutex. It is better to fix this in innodb itself since otherwise it may require changes outside it.
This affects both 5.5 and 5.6 trees.
After porting of twitter's timeout patch in /blueprints. launchpad. net/percona- server/ +spec/port- max-statement /bugs.launchpad .net/percona- xtradb- cluster/ 5.6/+bug/ 1233301
https:/
-time, it is possible for deadlock to occur when THD::awake is
invoked from within innodb itself. One is the case presented
here: https:/
where the wsrep code calls THD::awake during a BF abort and deadlocks
on lock_sys->mutex and trx->mutex. It is better to fix this in innodb
itself since otherwise it may require changes outside it.
This affects both 5.5 and 5.6 trees.