Opened 9 years ago

Closed 3 years ago

#2688 closed Bug (worksforme)

failed save() with postgresql sometimes doesn't throw error until next statement (which is 'set time zone')

Reported by: mail@… Owned by: zefciu
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: psycopg transactions timezone postgresql
Cc: mail@…, sam@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I was getting a 'programmingerror' when the session middleware tried to set the timezone, but as this works any other time it changes the session, I assumed that wasn't the real problem. executing the set time zone statement in psql worked too, so it seemed to be an earlier statement that was causing the error. I eventually tracked down the earlier statement that was causing the error (trying to set a DateField to a time.time() rather than a datetime instance) but what I don't understand is why this error wasn't reported when it happened.

I wondered if it was something to do with autocommit not happening until after the session had been updated so I used the manual transaction decorator to ensure the transaction was commited, but still no error. I noticed in ticket 852, kkennedy@… talks about the same behaviour. is psycopg not reporting the errors or is this a problem in django?

Change History (8)

comment:1 Changed 9 years ago by anonymous

  • Cc mail@… added

comment:2 Changed 8 years ago by mir

  • Needs tests set
  • Summary changed from failed save() doesn't throw error until next statement (which is 'set time zone') to failed save() with postgresql sometimes doesn't throw error until next statement (which is 'set time zone')
  • Triage Stage changed from Unreviewed to Accepted

As far as I know, the reason why sometimes an error is not detected with postgresql before the set timezone is still unknown, but I have seen enough reports in the mailing lists that I'm sure this is an issue. Any help in sorting this out appreciated. If you can provide a reproducible test case, please describe it here!

comment:3 Changed 8 years ago by anonymous

  • Cc sam@… added

comment:4 Changed 4 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from defect to Bug

comment:5 Changed 3 years ago by zefciu

  • Easy pickings unset
  • Triage Stage changed from Accepted to Ready for checkin
  • UI/UX unset

comment:6 Changed 3 years ago by zefciu

  • Has patch set
  • Needs tests unset
  • Triage Stage changed from Ready for checkin to Accepted

comment:7 Changed 3 years ago by zefciu

  • Owner changed from nobody to zefciu
  • Status changed from new to assigned

comment:8 Changed 3 years ago by zefciu

  • Has patch unset
  • Resolution set to worksforme
  • Status changed from assigned to closed

I have tried to reproduce this bug by putting the value of time.time() to DateField. My results:

  • In current version of django it simply doesn't pass the validation.
  • After disabling validation (by substituting all the .to_python() logic with return value the DatabaseError is returned immediately.

What's more. 5 years ago, when this bug was submitted psycopg was about 2.0.5. It's most likely that this effect was due to some bug in psycopg2, as it didn't happen with other backends. As nobody provided a reproducible case for this bug or submitted similar bugs from that time, we can assume that this bug was fixed.

I suggest to close this bug.

Note: See TracTickets for help on using tickets.
Back to Top