Christoph Zwerschke wrote:
SmokeyD schrieb:I was running SQLAlchemy 4.2 and just upgraded to 4.3, but this doesn't solve the problem. SQLAlchemy is indeed using psychopg2. Of course I can schedule a restart of TG after the restart of Postgres,but it would be nicer if this wasn't necessary. Especially in a production environment where there are many instances of Turbogears this would be annoying (although one could question if you would restart postgres in a production environment as well). I would like to submit a ticket somewhere about this though. Should I submit it with TG or with SQLAlchemy?This is definitely not a TG issue. You should ask on the SQLAlchemy whether the ability to transparently recover stale connections is a feature that is already available in SA's connection pooling, but just not working, or whether they plan to add this in a future release. Maybe they can recycle some code from DBUtils (http://www.w4py.org/DBUtils).
Actually, SQLAlchemy with psycopg2 handles this reasonably well.We're currently running our production servers on SA-0.3.11 and after a db restart they have a brief period where they don't connect to the db and then everything is fine (This is around five minutes after the db starts accepting connections again. it's definitely up within ten minutes.)
However, we aren't running with mod_python here, but as a stand-alone server which ProxyPass's to Apache. Perhaps mod_python throws a wrench into things?
-Toshio
signature.asc
Description: OpenPGP digital signature
