1

So I've updated django to 1.4.5 and postgres to 9.2.3 and psycopg2 to 2.4.6 . I runserver and everything looks ok, but when i go to localhost:8000 i see the infamous 'current transaction aborted..' on request.session.save() in sessions/middleware.py(36).

I ran syncdb and migrate, no errors or changes for that matter. I also added in 'DATABASES' - 'OPTIONS': {'autocommit': True, }, but still no help. And I also tried this:

from django.db import connection
connection._rollback()

in django shell.

I also tried to stop postgres with:

pg_ctl -D /usr/local/var/postgres stop -s -m fast

And i get:

pg_ctl: server does not shut down

Running pg -ef|grep postgres shows no hanging queries.

How can i resolve this block? How to find what causes it?

Answer: A summery of what i did to solve this error

I enabled sql logging:

DEBUG=True    
LOGGING = {
        'version': 1,
        'disable_existing_loggers': False,
        'handlers': {
            'null': {
                'level': 'DEBUG',
                'class': 'django.utils.log.NullHandler',
            },
            'console': {
                'level': 'DEBUG',
                'class': 'logging.StreamHandler',
                'formatter': 'simple'
            }
        },
        'loggers': {
            'django': {
                'handlers': ['console'],
                'level': 'DEBUG',
            },
        }
    }

This showed me all sql statements being executed, including the one causing Internal DB Error, which in my case was caused by django-axes(i upgraded it earlier to version 1.2.9).

django-axes requires certain tables to be created. Re-running syncdb didn't solve my problem b.c there was a change inside one of the tables (new field - username).

python manage.py sqlclear axes - showed me what tables to drop, so i went to psql and did that. After which i ran again python manage.py syncdb and got updated tables.

And then i found a bug inside __init__.py of axes module, in get_version() - wrong string formatting. Fixing that solved all this mess :)

Finally, a happy ending!

That1Guy
  • 7,075
  • 4
  • 47
  • 59
Neara
  • 3,693
  • 7
  • 29
  • 40
  • Find out what causes it and then fix the cause. That error really should not be happening. You dont need to resolve the block itself. If you have fixed the cause of the block then next request will go past that block and work just fine. – Odif Yltsaeb Feb 21 '13 at 11:19
  • @Zayatzz Would love to find what causes it. Any suggestions as to how? – Neara Feb 21 '13 at 12:14
  • Well go over your traceback. See what kind of functions are beeing used there. In my experience these kind of things often happen in some kind of pgsql functions/triggers which are our own creations. I have never seen Django cause these problems on its own. – Odif Yltsaeb Feb 21 '13 at 12:36
  • Following [this](http://stackoverflow.com/questions/9064018/how-to-debug-internal-error-current-transaction-is-aborted-commands-ignored-un) post's answer i found out what query caused me so much greif! Now I just need to find what exactly issues this query and make it behave properly. So far looks like django-axes is, yet again, at the root of my problems :/ – Neara Feb 21 '13 at 13:04
  • Awesome! Lets go out and get one cold beer now... Damn i need one too... – Odif Yltsaeb Feb 21 '13 at 14:02
  • Oh, by the way. You could change the header of your bug to contain reference to django-axes. Since the bug was caused by it and it would make it easyer to find for others - especially you were no nice and posted full solution. – Odif Yltsaeb Feb 21 '13 at 14:11
  • Yeah, cold beer is indeed in order! And i added django-axes to the header. Hope it will save others all those hours i waisted on figuring this one out. – Neara Feb 21 '13 at 14:19

0 Answers0