I'll make a release across the weekend. You should have a 2.5.1 by Monday.
Nice! Thanks.
Thank you again for fixing the same issue twice at 4 years distance. I'm
very curious about your setup: if you could spend two words on it we may
put together some stressing rig.
Glad to help. I think there is a combination of factors in our usage pattern of psycopg that increases the likelihood these kinds of issues surfacing:
1. We subclass the connection class and pass it in as connection_factory argument to psycopg2.connect() . Subclassing is necessary to make the garbage collector worry about this object having cyclic references and try tp_clear on it. This is how we end up in a place where the reference counting based destruction of the object on one thread coincides with the garbage collector trying to free the same object from another thread. The subclass definition of the connection class can simply be a "pass" statement and need not implement any actual functionality.
2. We have 100s of threads connecting to 100s of databases rationed out by a connection pool manager library. Connections are closed and opened frequently.
Please let me know if further information is needed.
Thanks,
Gangadharan