Opened 7 years ago

Closed 7 years ago

Last modified 3 years ago

#8315 closed (fixed)

MySQL Commands out of sync on attempt to rollback

Reported by: voidfiles@… Owned by: mtredinnick
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by mtredinnick)

I have newest code as of this ticket. This only happens when I run django through a fastCGI on dreamhost. I have built my own python, and mysqlDB so its not dreamhosts stuff. Followed the directions in the django tutorial. Happened after a checkout so that is why I think this might be a bug, and not a support issue.

Here is the Error dump.

 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: Traceback (most recent call last):
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 558, in run
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     protocolStatus, appStatus = self.server.handler(self)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 1112, in handler
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     result = self.application(environ, start_response)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 216, in __call__
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     response = self.get_response(request)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/core/handlers/base.py", line 124, in get_response
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     receivers = signals.got_request_exception.send(sender=self.__class__, request=request)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/dispatch/dispatcher.py", line 132, in send
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     response = receiver(signal=self, sender=sender, **named)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/db/__init__.py", line 56, in _rollback_on_exception
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     transaction.rollback_unless_managed()
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/db/transaction.py", line 157, in rollback_unless_managed
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     connection._rollback()
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/db/backends/mysql/base.py", line 227, in _rollback
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     BaseDatabaseWrapper._rollback(self)
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:   File "/home/varius_2/opt/lib/python2.5/site-packages/django/db/backends/__init__.py", line 32, in _rollback
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr:     return self.connection.rollback()
 /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: ProgrammingError: (2014, "Commands out of sync; you can't run this command now")

Attachments (2)

8315.diff (494 bytes) - added by kmtracey 7 years ago.
Catch ProgrammingError on attempt to rollback
8315-2.diff (523 bytes) - added by Karen Tracey <kmtracey@…> 7 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 7 years ago by Karen Tracey <kmtracey@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Specifics beyond 'not dreamhosts stuff' could be helpful here. What MySQLdb & MySQL levels exactly? I assume you are using InnoDB since the error sounds transaction-related? What exactly triggers the error? Any attempt to access any url on your site?

comment:2 Changed 7 years ago by voidfiles@…

Yea thanks for the response.

So here is what I get mysql
mysql Ver 14.12 Distrib 5.0.16, for pc-linux-gnu (i386) using readline 5.0

MySQL-python-1.2.2

I get the error when I try and access admin, and one other url

I am using MyISAM, not InnoDB

Thanks for telling me what elese to include I have never filled a ticket before.

comment:3 Changed 7 years ago by kmtracey

  • Owner changed from nobody to kmtracey
  • Status changed from new to assigned
  • Summary changed from Updated code to rev. 8350 to MySQL Commands out of sync on attempt to rollback

I think there are a couple of problems interacting here. First there is something weird causing ill-described "crashes" going on with sessions/cookies, see #8314 and various reports on the user's list today. The reason I think that is related to this report is that I just hit this traceback when I:

  • changed my settings.py to point to my test DB instead of my production DB
  • used the same browser I had been using to access my production DB to instead access the test DB, this caused a commands out of sync error/traceback
  • I then managed to avoid the traceback by clearing cookies from my browser, once I did that I could access the test DB admin

So the cookies/session oddness is one problem and is I think being looked into separately. The fact that the exception it caused resulted in a MySQL "Commands out of sync" error is a different problem which I will try looking into.

To voidfiles: try clearing cookies in your browser and see if that fixes the problem.

To anyone with trac superpowers: Could you fix the original description formatting? (Or if that is something mere mortals can do please tell me how, 'cause I don't know how to do it and this one is hurting my eyes.)

comment:4 Changed 7 years ago by kmtracey

  • Status changed from assigned to new
  • Triage Stage changed from Unreviewed to Accepted

Meant to change the triage stage, not assign to myself.

comment:5 Changed 7 years ago by mtredinnick

  • Description modified (diff)

Fixed description to stop Karen's eyes from hurting.

comment:6 Changed 7 years ago by voidfiles

clearing my cookies did allow me to get into the admin section.

Changed 7 years ago by kmtracey

Catch ProgrammingError on attempt to rollback

comment:7 Changed 7 years ago by kmtracey

Well, I attached a patch that at least causes the root problem (maximum recursion depth exceeded) to get reported. Attempt to rollback already caught/passed Database.NotSupportedError but did not catch ProgrammingError. I do not know why in this particular case we see ProgrammingError, or if it always correct to catch and ignore it. In this particular case it seems good, since failing to catch it obscured the real error and instead reported something completely unhelpful. But might there be a case where we'd rather want to know rollback reported a ProgrammingError? Someone with more transaction smarts than me maybe knows.

comment:8 Changed 7 years ago by Karen Tracey <kmtracey@…>

  • Owner changed from kmtracey to nobody

I've done as much as I can with this one.

comment:9 Changed 7 years ago by mtredinnick

  • milestone set to 1.0
  • Triage Stage changed from Accepted to Design decision needed

I'm not completely happy with this (although thanks for working out the problem). A ProgrammingError isn't going to be raised by the database and indicates some kind of real developer-level problem. I'm just about to commit a fix for the root problem (#8314), which should fix the immediate issue. Will leave this open for a bit to think about it. Right now, I'm inclined to not apply it, but I may be missing something.

Changed 7 years ago by Karen Tracey <kmtracey@…>

comment:10 Changed 7 years ago by Karen Tracey <kmtracey@…>

I attached an alternative version of the patch that catches the rollback exception within _rollback_on_exception. Here we know we're already dealing with handling an error case, so the question is which error do we want to report? If the answer is we want to report the original exception, not the failure on rollback, then I think we want the patch. I'm more comfortable with this version of the patch since it seems targeted at ensuring the root error is reported without possibly hiding other valid errors that should be raised when a rollback fails. BTW the recursion exception in the case where MySQL is being used seems to be getting hit inside MySQLdb:

File "/home/kmt/django/trunk/django/db/models/sql/query.py" in execute_sql
  1614.         cursor.execute(sql, params)
File "/home/kmt/django/trunk/django/db/backends/util.py" in execute
  19.             return self.cursor.execute(sql, params)
File "/var/lib/python-support/python2.5/MySQLdb/cursors.py" in execute
  166.             self.errorhandler(self, exc, value)
File "/var/lib/python-support/python2.5/MySQLdb/connections.py" in defaulterrorhandler
  File "/home/kmt/django/trunk/django/db/models/sql/query.py" in execute_sql
  1614.         cursor.execute(sql, params)
File "/home/kmt/django/trunk/django/db/backends/util.py" in execute
  19.             return self.cursor.execute(sql, params)
File "/var/lib/python-support/python2.5/MySQLdb/cursors.py" in execute
  166.             self.errorhandler(self, exc, value)
File "/var/lib/python-support/python2.5/MySQLdb/connections.py" in defaulterrorhandler
  35.     raise errorclass, errorvalue

Exception Type: RuntimeError at /admin/
Exception Value: maximum recursion depth exceeded
35.     raise errorclass, errorvalue

Exception Type: RuntimeError at /admin/
Exception Value: maximum recursion depth exceeded

so it may be that the whole connection is left in a state where any attempt to do anything besides close it generates an error? In cases where this has happened I think it will be generally more useful to be told about what caused the first error, not the fact that attempting to rollback failed.

comment:11 Changed 7 years ago by Karen Tracey <kmtracey@…>

My center mouse button has developed a bad habit of double-pasting on me. It's supposed to be:

File "/home/kmt/django/trunk/django/db/models/sql/query.py" in execute_sql
  1614.         cursor.execute(sql, params)
File "/home/kmt/django/trunk/django/db/backends/util.py" in execute
  19.             return self.cursor.execute(sql, params)
File "/var/lib/python-support/python2.5/MySQLdb/cursors.py" in execute
  166.             self.errorhandler(self, exc, value)
File "/var/lib/python-support/python2.5/MySQLdb/connections.py" in defaulterrorhandler
  35.     raise errorclass, errorvalue

Exception Type: RuntimeError at /admin/
Exception Value: maximum recursion depth exceeded

which doesn't look quite so insane as the first version.

comment:12 Changed 7 years ago by mtredinnick

  • Owner changed from nobody to mtredinnick
  • Triage Stage changed from Design decision needed to Accepted

heh. That second paste makes a lot more sense. :-)

I like the second patch better, for the reasons you mention. It doesn't hide the real problem and just feels like it's catching things at the right level (plus it will work for all backends). If I don't get nervous about it in the interim, I'll commit this later today.

comment:13 Changed 7 years ago by Karen Tracey <kmtracey@…>

Nervous? What could possibly make you nervous? Perfectly obvious fix, it can't possibly break anything, just like some others this week. :-)

comment:14 Changed 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

(In [8411]) Fixed #8315 -- If an exception is raised whilst trying to rollback a
transaction (after another exception in the code), make sure the original
exception is reported, rather than the rollback-generated one. The latter is
almost certainly a consequence of the former. Patch from Karen Tracey.

comment:15 Changed 3 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top