Django+Postgres: “current transaction is aborted, commands ignored until end of transaction block”

Question

I\'ve started working on a Django/Postgres site. Sometimes I work in manage.py shell, and accidentally do some DB action that results in an error. Then I am una

Answer 1

Check this

The quick answer is usually to turn on database level autocommit by adding:

'OPTIONS': {'autocommit': True,}

To the database settings.

Answer 2

this happens to me sometimes, often it's the missing

manage.py migrate 

or

manage.py syncdb

as mentioned also here

it also can happen the other way around, if you have a schemamigration pending from your models.py. With south you need to update the schema with.

manage.py schemamigration mymodel --auto

Answer 3

If you are using a django version before 1.6 then you should use Christophe's excellent xact module.

xact is a recipe for handling transactions sensibly in Django applications on PostgreSQL.

Note: As of Django 1.6, the functionality of xact will be merged into the Django core as the atomic decorator. Code that uses xact should be able to be migrated to atomic with just a search-and-replace. atomic works on databases other than PostgreSQL, is thread-safe, and has other nice features; switch to it when you can!

Answer 4

I had this error after restoring a backup to a totally empty DB. It went away after running:

./manage syncdb 

Maybe there were some internal models missing from the dump...

Answer 5

I add the following to my settings file, because I like the autocommit feature when I'm "playing around" but dont want it active when my site is running otherwise.

So to get autocommit just in shell, I do this little hack:

import sys
if 'shell' in sys.argv or sys.argv[0].endswith('pydevconsole.py'):
    DATABASES['default']['OPTIONS']['autocommit'] = True

NOTE: That second part is just because I work in PyCharm, which doesnt directly run manage.py

Answer 6

If you happen to get such an error when running migrate (South), it can be that you have lots of changes in database schema and want to handle them all at once. Postgres is a bit nasty on that. What always works, is to break one big migration into smaller steps. Most likely, you're using a version control system.

• Your current version
• Commit n1
• Commit n2
• Commit n3
• Commit n4 # db changes
• Commit n5
• Commit n6
• Commit n7 # db changse
• Commit n8
• Commit n9 # db changes
• Commit n10

So, having the situation described above, do as follows:

• Checkout repository to "n4", then syncdb and migrate.
• Checkout repository to "n7", then syncdb and migrate.
• Checkout repository to "n10", then syncdb and migrate.

And you're done. :)

It should run flawlessly.