PostgreSQL backend reporting "SET TIME ZONE" error instead of the real error

[anonymous]

Hello,

I use svn-version Django and @login_required decorator. I got before public login-screen (login to admin works good):

  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
    result = object(req)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 177, in handler
    return ModPythonHandler()(req)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 154, in __call__
    response = middleware_method(request, response)

  File "/usr/lib/python2.4/site-packages/django/contrib/sessions/middleware.py", line 81, in process_response
    session_key = request.session.session_key or Session.objects.get_new_session_key()

  File "/usr/lib/python2.4/site-packages/django/contrib/sessions/models.py", line 21, in get_new_session_key
    self.get(session_key=session_key)

  File "/usr/lib/python2.4/site-packages/django/db/models/manager.py", line 67, in get
    return self.get_query_set().get(*args, **kwargs)

  File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 211, in get
    obj_list = list(clone)

  File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 103, in __iter__
    return iter(self._get_data())

  File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 430, in _get_data
    self._result_cache = list(self.iterator())

  File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 170, in iterator
    cursor = connection.cursor()

  File "/usr/lib/python2.4/site-packages/django/db/backends/postgresql/base.py", line 47, in cursor
    cursor.execute("SET TIME ZONE %s", [settings.TIME_ZONE])

ProgrammingError: ERROR:  current transaction is aborted, commands ignored until end of transaction block

SET TIME ZONE 'Europe/Warsaw'

What can I do?

[Gary Wilson <gary.wilson@…>]

The ticketing system is for bugs only. Please use the ​django-users mailing list for assistance, and if it is determined that the problem you are experiencing is indeed a bug, then come back here and file a ticket.

It's probable that you had some code that raised an error and you did not rollback the database transaction, and on the database query following the one that caused an error you got the errors you posted above.

See the ​transaction documentation.

[Dmytri Kleiner]

I am having the exact same problem (with 0.95/twisted), and it has nothing to do with the hypothetical condition described by Gary Wilson above, there is something wrong with the login_required decorator. When I use the decorator from the admin (staff_member_required) it works just fine, when I use login_required it fails as described. Problem is with generic views you can not specify _which_ decorator to use, so it seems to me generic views are essential broken in .95 if authentication is needed (maybe it's only with twisted and/or postgres).

[mir@…]

The traceback above is the result of a previous error. It's impossible to say what has caused it without more information. And it is highly probable that it's a user error (but it still can be a bug). That's why Gary referred the anonymous reporter to the django user mailing list.

Please, report your problems there, and only open a ticket when it turns out to be a bug unless it's obvious. It's not that nobody is willing to help, but the mailing lists are a better place.

[Thomas Steinacher <tom@…>]

"The traceback above is the result of a previous error. It's impossible to say what has caused it without more information."

Yeah, and THIS is the bug. It is PostgreSQL related. Django should report the real error (the previous error), like on other database backends, and not the "SET TIME ZONE" error. There is no way to say what the previous error was without using some crappy print-statements. It is impossible to develop using the PostgreSQL backend.

[James Bennett]

What's a bit weird about this is that there's nowhere in our PostgreSQL backend that I can spot which would trap errors; I can't say definitively one way or another, but it might be worth looking upstream at psycopg as well, since it should -- as far as I know -- be raising OperationalError, ProgrammingError or IntegrityError and we don't catch those.

[Jacob]

Marking wontfix, again, for the reasons shown above, and since the anonymous OP isn't around any more to discuss this.

[marc@…]

If you experience this problem, looking at the PostgreSQL log files (look up the "ERROR REPORTING AND LOGGING" section in postgresql.conf) will help. I do think this is a bug, Django should report the real error, not the "SET TIMEZONE.." error.

With my app I get from Django:

Traceback (most recent call last):

... etc...

ProgrammingError: ERROR: current transaction is aborted, commands ignored until end of transaction block

SET TIME ZONE 'Europe/Amsterdam'

And in pg_log I see:

2007-01-23 12:50:35 ERROR: duplicate key violates unique constraint "composition_pkey"

This is the error Django should report. Of course it is a user (programming) error, but having the right error to start with is essential. At least the PostgreSQL log provides a workable workaround.

Marc

[Michael Radziej <mir@…>]

marc and tom: I share your opinion that django should report the database error. But this is different from what this ticket is about.

Well, why not open a different ticket? I'd ask you to provide a minimal test case that exhibits the described behaviour. Ticket reopen doesn't work currently, anyway.