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

Reply via email to