https://bugzilla.wikimedia.org/show_bug.cgi?id=70153
Bug ID: 70153
Summary: MessageGroupStats co-operative deadlock with
transactions and GET_LOCK
Product: MediaWiki extensions
Version: master
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Translate
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected]
Web browser: ---
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
