I have implemented commit-lock-timeout for PostgreSQL 9.3+ in a fork on github.
See: https://github.com/upiq/relstorage/commit/6ac7bf31ce3491ff87f5c138c892c0c0906c12ac However, I am unclear though what the effect of using the default 30 second lock timeout is for transactions that take a long time to commit? Or is this lock timeout just used at the very beginning of a transaction? Forgive my ignorance. Any input on this change? Sean On Thu, Jul 17, 2014 at 1:20 PM, Sean Upton <sdup...@gmail.com> wrote: > Any insights from RelStorage users appreciated on this; > > I have a case where multiple Zope2 instances (each with four threads) > get stuck (most/all threads) waiting on execution of LOCK TABLE > statements (presumably stuck commits) in > relstorage.adapters.locker.PostgreSQLLocker.hold_commit_lock [1]. > > Any ideas on what I should be looking for in PostgreSQL and possible > causes in my application? > > > Sean > > > [1] Call stack via SIGUSR1 to an instance: http://pastie.org/9400704 _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
