trouble deploying branch.sql for #1582

[chadwhitacre]

Traceback (most recent call last):
  File "aspen/website.py", line 81, in handle_safely
    response = self.handle(request)
  File "aspen/website.py", line 114, in handle
    response = request.resource.respond(request)
  File "aspen/resources/dynamic_resource.py", line 52, in respond
    exec self.pages[1] in context
  File "/app/www/%username/widget.html.spt", line 3, in <module>
    participant = Participant.from_username(path['username'])
  File "gittip/models/participant.py", line 74, in from_username
    return cls._from_thing("username_lower", username.lower())
  File "gittip/models/participant.py", line 97, in _from_thing
    """.format(thing), (value,))
  File "postgres/__init__.py", line 463, in one
    return cursor.one(sql, parameters, default)
  File "postgres/cursors.py", line 105, in one
    out = self._some(sql, parameters, lo=0, hi=1)
  File "postgres/cursors.py", line 134, in _some
    return self.fetchall()
  File "psycopg2/extras.py", line 314, in fetchall
    ts = super(NamedTupleCursor, self).fetchall()
  File "psycopg2/extras.py", line 838, in parse
    (len(self.atttypes), self.name, len(tokens)))
DataError: expecting 20 components for the type participants, 21 found instead

https://app.getsentry.com/gittip/gittip/group/8568894/

[chadwhitacre]

Ref. #1582

[chadwhitacre]

Seems like it has something to do with that "::participants" thing.

IRC

[chadwhitacre]

Ticketed w/ psycopg:

psycopg2 caches the attributes of composite types, so that when the type is altered in the database, the next attempt to cast that type in psycopg2 results in a DataError. This seems to introduce a race condition between modifying the database and restarting processes accessing the database.

http://psycopg.lighthouseapp.com/projects/62710/tickets/183

[chadwhitacre]

For now the workaround is to apply-and-restart. Would be great to find a better workaround. Per IRC, let's carry the conversation forward over on the psycopg ticket.

[dvarrazzo]

Hi, thank you for reporting the issue. The composite cache is local to where register_composite was called (globally, the connection, or the cursor). You can avoid the problem using it in a restricted scope (e.g. on a cursor, and dropping the cursor after the type is changed). Alternatively just rerun register_composite with the same arguments after changing the type.

Hope this helps.

[chadwhitacre]

Thanks @dvarrazzo, let's carry on the conversation on http://psycopg.lighthouseapp.com/projects/62710-psycopg/tickets/183.

[chadwhitacre]

I've ticketed this for postgres.py as liberapay/postgres.py#26.