DatabaseError: current transaction is aborted, commands ignored until end of transaction block?

Posted on

Question :

DatabaseError: current transaction is aborted, commands ignored until end of transaction block?

I got a lot of errors with the message :

"DatabaseError: current transaction is aborted, commands ignored until end of transaction block"

after changed from python-psycopg to python-psycopg2 as Django project’s database engine.

The code remains the same, just don’t know where those errors are from.

Asked By: jack


Answer #1:

This is what postgres does when a query produces an error and you try to run another query without first rolling back the transaction. (You might think of it as a safety feature, to keep you from corrupting your data.)

To fix this, you’ll want to figure out where in the code that bad query is being executed. It might be helpful to use the log_statement and log_min_error_statement options in your postgresql server.

Answered By: ?s??o?

Answer #2:

To get rid of the error, roll back the last (erroneous) transaction after you’ve fixed your code:

from django.db import transaction

You can use try-except to prevent the error from occurring:

from django.db import transaction, DatabaseError
except DatabaseError:

Refer : Django documentation

Answered By: Anuj Gupta

Answer #3:

So, I ran into this same issue. The problem I was having here was that my database wasn’t properly synced. Simple problems always seem to cause the most angst…

To sync your django db, from within your app directory, within terminal, type:

$ python syncdb

Edit: Note that if you are using django-south, running the ‘$ python migrate’ command may also resolve this issue.

Happy coding!

Answered By: Michael Merchant

Answer #4:

In Flask you just need to write:

curs = conn.cursor()

P.S. Documentation goes here

Answer #5:

In my experience, these errors happen this way:

    # transaction on DB is now bad

# transaction on db is still bad
code_that_executes_working_query() # raises transaction error

There nothing wrong with the second query, but since the real error was caught, the second query is the one that raises the (much less informative) error.

edit: this only happens if the except clause catches IntegrityError (or any other low level database exception), If you catch something like DoesNotExist this error will not come up, because DoesNotExist does not corrupt the transaction.

The lesson here is don’t do try/except/pass.

Answered By: priestc

Answer #6:

I think the pattern priestc mentions is more likely to be the usual cause of this issue when using PostgreSQL.

However I feel there are valid uses for the pattern and I don’t think this issue should be a reason to always avoid it. For example:

    profile = user.get_profile()
except ObjectDoesNotExist:
    profile = make_default_profile_for_user(user)


If you do feel OK with this pattern, but want to avoid explicit transaction handling code all over the place then you might want to look into turning on autocommit mode (PostgreSQL 8.2+):

DATABASES['default'] = {
    #.. you usual options...
    'OPTIONS': {
        'autocommit': True,

I am unsure if there are important performance considerations (or of any other type).

Answered By: Sebastian

Answer #7:

If you get this while in interactive shell and need a quick fix, do this:

from django.db import connection

originally seen in this answer

Answered By: tutuDajuju

Answer #8:

just use rollback

Example code

    cur.execute("CREATE TABLE IF NOT EXISTS test2 (id serial, qa text);")
    cur.execute("CREATE TABLE IF NOT EXISTS test2 (id serial, qa text);")
Answered By: Umer

Leave a Reply

Your email address will not be published. Required fields are marked *