This is related to bug 51410, but looks like a new form of the old problem introduced by that fix.
On mediawikiwiki master queries experience lock-wait-timeout in what looks like an effective deadlock between transactions and co-operative locks.
SELECT /* MessageGroupStats::forItemInternal */ GET_LOCK('MessageGroupStats:modify:page-MediaWiki-Vagrant', 1) AS lockstatus;
UPDATE /* LinksUpdate::updateLinksTimestamp */ page SET page_links_updated = '20140829051059' WHERE page_id = '226112';
The queries are unrelated. The LinksUpdate query is perfectly ok until MessageGroupStats appears.
From the database end, it looks like MessageGroupStats get_lock() is called in a loop by a connection which can already have an open transaction with row locks on the page and translate_groupstats tables.
When the co-op lock is not acquired quickly, MessageGroupStats transactions bottleneck and queue up, collectively holding many row locks and blocking other queries like LinksUpdate *and whichever MessageGroupStats connection already holds the co-op lock*.
We should not be combining transactions and co-operative locking in this manner.
Version: master
Severity: major