Failure to explicity commit or rollback transaction causes inefficient use of connection pool and log spam

Bug #1200556 reported by Stuart Bishop
6
This bug affects 1 person
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://stackoverflow.com/questions/8198990/pgbouncer-closing-because-unclean-server-on-every-connection

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://initd.org/psycopg/docs/connection.html#connection.close.

The recommended solution is to make Django issue a ROLLBACK before closing the database connection

if con.status == psycopg2.extensions.STATUS_IN_TRANSACTION:
    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().

Stuart Bishop (stub)
Changed in django:
importance: Undecided → Unknown
status: New → Unknown
Revision history for this message
Stuart Bishop (stub) wrote :

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?

Changed in canonical-identity-provider:
importance: Undecided → Medium
Haw Loeung (hloeung)
tags: added: canonical-losa-isd
Dave Morley (davmor2)
Changed in canonical-identity-provider:
status: New → Confirmed
assignee: nobody → Ubuntu One web team (ubuntuone-web)
tags: added: u1-by-dev u1-on-production
Curtis Hovey (sinzui)
Changed in canonical-identity-provider:
assignee: Registry Administrators (registry) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.