Thanks for replying so fast. I understand using the event system to track the stack trace, however how would you recommend implementing a timeout for "checked out" connections, to find connections stuck in a checked out state? I dont think I would actually use this in production, but on a beta/lab version of the app to find problems,
Is it easier or even possible to discover these frozen checked out connections using simply postgres queries, like pg_stat_activity? If a query completes but is never returned back to the pool, would pg_stat_activity see that differently then a connection that is checked in, could this be used to find what query(s) ran on this connection and track it back to a method that never closed its session? I just need a reliable way to discover connections that are never closed and stuck in a checked out state. I do use special annotation methods on all my web calls to automatically commit or rollback, but the other day our DB got into a state where the pool_size and overflow was probably reached, either that or there was some query maxing out the cpu causing everything to slow down. I just need to do some debugging to figure out where this problem can occur at. Thanks -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
