Description
See @davepacheco 's comment on : #4093 (comment) for some context:
Sorry, what I meant was not to try to track whether a transaction was created, but rather always issue
ROLLBACK
when a connection is put back into the pool. This will fail if there was no open transaction and we'd ignore the error in this context. This would be a fallback to catch cases like this, rather than relying on the consuming code to have correctly tracked this information.What I meant about common practice is that I think other connection pools have the notion of "stuff that gets done when a connection gets put back into the pool to ensure that connections all come out of the pool in a consistent state". Here's an example from deadpool's PostgreSQL crate:
https://docs.rs/deadpool-postgres/latest/deadpool_postgres/enum.RecyclingMethod.htmlThey provide a few different choices with tradeoffs in terms of cost vs. completeness.
RecyclingMethod::Fast
does basically nothing.RecyclingMethod::Clean
runs several SQL statements that close open cursors, reset any connection-local parameters that were set withset
, unlock any locks that were somehow left locked, etc. (I'm surprised they don't seem to do a rollback!)
I could not find an equivalent method in bb8, to clean connections. We could upstream this support, or consider an option like #4192