Jeff Frost <jeff at frostconsultingllc.com> writes:
> I think the deadlocks aren't load related but speed related.  That is,
> if the acquiring of all the locks by the execute script takes longer
> on a slower machine, the window of opportunity for one of these
> selects to cause a deadlock seems greater, no?  They do seem to happen
> on the slower machine more regularly than the faster one.

The problem had nothing to do with deadlocks, per se, but rather with
the fact that a refactoring of the code *broke* things by taking out a
leading "begin;" statement.

It should present no *fundamental* problem if the node hits a
deadlock; if the deadlock affects the "EXECUTE SCRIPT" event, then the
worst that should happen is that the work gets rolled back, and ten
seconds later, the node retries, hopefully with greater success.

The fix for this has been committed to the 1.2 branch (never was a
problem in 2.0), so that we should have this addressed RSN.
-- 
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxdatabases.info/info/nonrdbms.html
"High-level languages are a pretty good indicator that all else is
seldom equal." - Tim Bradshaw, comp.lang.lisp