Intermittent deployment "Deadlock found when trying to get lock" during fixture loading



11 months ago
18 days ago


(Reporter: emorley, Assigned: emorley)




(2 attachments)



11 months ago
Twice in a row whilst trying to deploy to production (the third deploy succeeded), the deploy failed during the release phase step, in the ` loaddata` management command, with:

`model.FailureClassification(pk=1): (1213, 'Deadlock found when trying to get lock; try restarting transaction')`

...whilst trying to load `fixtures/failure_classification.json`.

This is presumably due to contention with other queries running at the time.

The annoying thing about this is that the fixture file hadn't actually changed, so nothing needed updating. Perhaps we should refactor our use of fixtures to only update things that have changed?

Log excerpt:

-----> PRE-DEPLOY: Loading initial data...
Traceback (most recent call last):
  File "/app/treeherder/model/management/commands/", line 14, in handle
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/management/", line 131, in call_command
    return command.execute(*args, **defaults)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/management/", line 330, in execute
    output = self.handle(*args, **options)
  File "/app/.heroku/python/lib/python2.7/site-packages/newrelic/api/", line 107, in literal_wrapper
    return wrapped(*args, **kwargs)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/management/commands/", line 69, in handle
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/management/commands/", line 109, in loaddata
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/management/commands/", line 175, in load_label
  File "/app/.heroku/python/lib/python2.7/site-packages/django/core/serializers/", line 205, in save
    models.Model.save_base(self.object, using=using, raw=True, **kwargs)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/", line 838, in save_base
    updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/", line 905, in _save_table
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/", line 955, in _do_update
    return filtered._update(values) > 0
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/", line 664, in _update
    return query.get_compiler(self.db).execute_sql(CURSOR)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/sql/", line 1204, in execute_sql
    cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
  File "/app/.heroku/python/lib/python2.7/site-packages/django/db/models/sql/", line 899, in execute_sql
    raise original_exception
django.db.utils.OperationalError: Problem installing fixture '/app/treeherder/model/fixtures/failure_classification.json': Could not load model.FailureClassification(pk=1): (1213, 'Deadlock found when trying to get lock; try restarting transaction')

Original logs:

Comment 1

10 months ago
And again, but on stage:

Comment 10

9 months ago
This issue is starting to get annoying.


9 months ago
Priority: P2 → P1


9 months ago
Assignee: nobody → emorley

Comment 18

8 months ago
So I had an initial look into this and we seem to just be using the native Django fixtures, so not sure what we can do to fix this? It seems like this is something that Django should handle better, and we should file upstream?


8 months ago
Assignee: emorley → nobody

Comment 19

8 months ago
Django describes[1] fixtures like so on their topic page:

> It’s sometimes useful to pre-populate your database with hard-coded data when you’re first setting up an app.

and your comment earlier Ed about our use of them:

> the fixture file hadn't actually changed, so nothing needed updating

makes a really good point that we're misusing them.

Having looked at all the fixtures we're loading I think most are candidates for conversion to Field.choices [2].  There are a couple that need some more thought given to them (although there's one that's templating so should probably be in a template) but at least reducing the number we load will hopefull reduce the frequency of deadlocks as a start.


Comment 20

7 months ago
Yeah good ideas :-)

Happened again today (the frequency has dropped though):

Comment 24

4 months ago
This is still happening multiple times a week (and/or day), eg:
Yeah, I just hit it again on stage yesterday, fwiw.

Comment 27

21 days ago
Commit pushed to master at
Bug 1428031 - Heroku: Retry load_initial_data up to 5 times (#4186)

To work around the intermittent MySQL deadlocks encountered during
a small percentage of deployments. This will ensure deployments don't
cause email spam to app collaborators and Heroku admins, as well as
saving us from having to manually retry the release each time it

The `IGNORE_PREDEPLOY_ERRORS` option has also been removed, since
it's mostly redundant with `SKIP_PREDEPLOY`.


21 days ago
Assignee: nobody → emorley
Last Resolved: 21 days ago
Resolution: --- → FIXED

Comment 30

18 days ago
Commit pushed to master at
Bug 1428031 - Heroku: Increase max load_initial_data retries to 10 (#4203)

Since there was still a deploy failure after five attempts here:
You need to log in before you can comment on or make changes to this bug.