cubicweb #344870 no more rollback in repository._free_pool may cause pb [deprecated]

this call to rollback in repository._free_pool method has been removed recently (eg since 3.2.X ?), because some profiling has shown it was an important performance penalty.

But it seems that even read-only transaction may hold some lock susceptible to bloc some other transaction. This has been seen during docaster 0.8 migration where a read pool was freed, leaving a 'idle in transaction' postgres connection; then another pool was affected to the session which was trying to do some alter table, which was then indefinitly waiting for the other transaction lock to be released. Those are my conclusing, providing I've not missed an important point.


  • is this only a pb because of the ALTER query ? (in which case we can suppose it's safe to leave it as it is and only fix this during migration)
  • does this behaviour different between DBMS ? (much probably)
  • why systematic rollback in free_pool was so costly ? is a commit less expensive ? profile...
done in<not specified>
load left0.000
closed by<not specified>