Бесконечные проблемы с транзакциями после обновления mysql 5.0-> 5.6

Я обновил весь наш сервер mysql db с 5.0 до 5.6, включая изменение несколько table в innodb, и с тех пор у нас не было ничего, кроме проблем с бесконечными транзакциями. У меня все еще есть промежуточный сервер, использующий 5.0, и я могу подтвердить, что мы получаем только остановленные транзакции на новом сервере базы данных. Оба сервера работают в режиме tx_isolation = REPEATABLE-READ (http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html ). Я почти уверен, что все задействованные таблицы - это InnoDB для обоих серверов.

Итак, простой пример проблемы, с которой мы столкнулись, - это некий процесс, который отправляет приветственные письма, который запускается как дочерний элемент супервизора (не очень важно). На этапе env с mysql 5.0 соединение длится несколько минут и не имеет открытых транзакций:

From show full processlist:
1639945 dbuser  <app-stage>:54536   db  Sleep   246     NULL

InnoDB transaction logs:
<nothing>

Точно такая же программа в нашей производственной среде с mysql 5.6 и внезапным потомком-демоном, который блокирует действительно важные таблицы и никогда не освобождает их.

From show full processlist:
28674638    dbuser  <app-prod>:54836    db  Sleep   67131   NULL

Innodb transaction:
---TRANSACTION 90461789, ACTIVE 67062 sec
MySQL thread id 28674638, OS thread handle 0x7f8ab934f700, query id 758722407 <app-prod> dbuser cleaning up
Trx read view will not see trx with id >= 90461790, sees < 89033402

Когда это не вызывает ужасных проблем, транзакция выглядит так:

---TRANSACTION 111578756, not started
MySQL thread id 42149496, OS thread handle 0x7f8ac29b4700, query id 975441865 <app-prod> dbuser cleaning up

У кого-нибудь есть предложения? Я вроде как подумываю о включении режима транзакции чтения без фиксации, но ... это похоже на исправление для другой проблемы, и мне действительно нужно знать, в чем заключается исходная проблема!