Since the code push on saturday (tracking flags) we have seen quite a bit of these errors come into errormill: DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction [for Statement "INSERT INTO bugs_activity (bug_id, who, bug_when, fieldid, removed, added, comment_id) VALUES (?, ?, ?, ?, ?, ?, ?)" with ParamValues: 0='436984', 1='485014', 2='2013-10-13 13:43:06', 3='37', 4='', firstname.lastname@example.org', 6=undef] at /data/www/bugzilla.mozilla.org/Bugzilla/Bug.pm line 4074. This could be related to the recent changes in the way the LogActivityEntry is recorded to improve performance, The bug question is that the activity entries are being lost when the changes are still made to the bug? Or does the whole thing roll back? Will investigate further. Does using 'state' for the statement handle cause the increase lock time when several processes are trying to access the table concurrently? dkl
I've hit it twice myself. The whole change gets rolled back (At least I don't get a mid-air when I hit reload and okay it to re-POST)
bug 922304 (via bug 922304) is the most likely culprit here. i've reverted that change: Committing to: bzr+ssh://email@example.com/bmo/4.2/ modified Bugzilla/Bug.pm Committed revision 9061. i'll leave this bug open and will close should the errors stop.
Assignee: nobody → glob
Summary: Multiple lock wait timeout exceeded errors since this past weekends update, related to recent LogActivityEntry changes maybe → Multiple lock wait timeout exceeded errors on the bugs_activity table
looks like this has fixed it. there's more comments in the upstream bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.