Django

Code

Ticket #3179 (closed: wontfix)

Opened 2 years ago

Last modified 2 years ago

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

Reported by: anonymous Assigned to: adrian
Milestone: Component: Database layer (models, ORM)
Version: SVN Keywords:
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

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?

Attachments

Change History

12/21/06 19:02:20 changed by Gary Wilson <gary.wilson@gmail.com>

  • status changed from new to closed.
  • resolution set to invalid.

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.

01/10/07 14:44:38 changed by Dmytri Kleiner

  • status changed from closed to reopened.
  • resolution deleted.
  • component changed from Contrib apps to Generic views.

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).

01/11/07 09:06:04 changed by mir@noris.de

  • status changed from reopened to closed.
  • resolution set to invalid.

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.

01/11/07 10:01:22 changed by Thomas Steinacher <tom@eggdrop.ch>

  • status changed from closed to reopened.
  • resolution deleted.
  • component changed from Generic views to Database wrapper.
  • summary changed from problem with login - transaction is aborted to PostgreSQL backend reporting "SET TIME ZONE" error instead of the real error.

"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.

01/11/07 13:40:47 changed by ubernostrum

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.

01/11/07 15:38:06 changed by jacob

  • status changed from reopened to closed.
  • resolution set to wontfix.

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

01/23/07 05:57:44 changed by marc@marcdegraauw.com

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

01/23/07 06:25:44 changed by Michael Radziej <mir@noris.de>

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.

Add/Change #3179 (PostgreSQL backend reporting "SET TIME ZONE" error instead of the real error)




Change Properties
Action