Sometimes Django request fails with non-informative exception:
psycopg2.ProgrammingError : current transaction is aborted, commands
ignored until end of transaction block
It's a result of a strong PostgreSQL data protection, anyway thru this, you
can't comfortably reveal the real error caused by the previous database
statement.
Often recommended hack is to decorate the failing code like this:
try:
... critical block ...
except:
from django.db import connection
connection._rollback()
raise
But I have quickier tip:
Having a proper PostgreSQL logging, just peek to its system log and you'll
find the failing statement you're interested in as well as the second one
causing the visible abort.
T.
|
