Failure to explicity commit or rollback transaction causes inefficient use of connection pool and log spam
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical SSO provider |
Confirmed
|
Medium
|
Unassigned | ||
Django |
Unknown
|
Unknown
|
Bug Description
A disk space alert let us to realize we are suffering from the problem described at http://
What is happening is that psycopg2 stopped explicitly issuing a ROLLBACK statement on close. This saves a round trip, but is annoying because pgbouncer drops drops the backend connection to the database rather than reuse it. This behavior can be defended, although the reasons seem more esoteric and low level (data in flight, postgresql connection protocol stuff). In any case, the psycopg2/pgbouncer issue is well known enough that it has a special mention in the docs at http://
The recommended solution is to make Django issue a ROLLBACK before closing the database connection
if con.status == psycopg2.
con.rollback()
con.close()
This could be fixed easily enough in Django upstream by providing a custom Connection class that has the more intelligent close().
Changed in django: | |
importance: | Undecided → Unknown |
status: | New → Unknown |
tags: | added: canonical-losa-isd |
Changed in canonical-identity-provider: | |
status: | New → Confirmed |
assignee: | nobody → Ubuntu One web team (ubuntuone-web) |
tags: | added: u1-by-dev u1-on-production |
Changed in canonical-identity-provider: | |
assignee: | Registry Administrators (registry) → nobody |
Simple workaround seems to be to always flag the transaction as dirty.
As best I can tell, this sort of issue was supposed to have been resolved in Django around 1.3, which points at our code?