Karl Fogel <kfogel@newton.ch.collab.net> writes:
> I ran five stress.pl's with 5194 subtracted, and got one instance of
> the famous error:
>
> Committing:
> Sending wcstress.24092/trunk/bar1/foo1
> Sending wcstress.24092/trunk/bar2/foo1
> Sending wcstress.24092/trunk/bar2/foo2
> Sending wcstress.24092/trunk/foo2
> Transmitting file data .subversion/libsvn_client/commit.c:670: \
> (apr_err=160020)
> svn: Item already exists in filesystem
> svn: Commit failed (details follow):
> subversion/libsvn_fs/bdb/nodes-table.c:146: (apr_err=160020)
> svn: successor id `0.0.1z3' (for `0.0.1ym') already exists \
> in filesystem '/home/kfogel/src/stress/repostress/db'
> subversion/libsvn_fs/bdb/bdb-err.c:61: (apr_err=160030)
> svn: Berkeley DB deadlock error
> svn: Berkeley DB error while reading node revision for \
> filesystem /home/kfogel/src/stress/repostress/db:
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
> unexpected commit fail: exit status: 256
That's bad. As far as filesystem logic goes, this error can only
happen when two processes have called svn_fs__dag_clone_root() with
the same transaction id. Now, I have no idea how that can happen --
allocate_txn_id() increments ...
Oh wait.
I wonder if this is another retry_txn() kinda thing, where someone is
using stale information that was invalidated by a Berkeley txn that
needed to be retried. Hm...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 4 05:53:35 2003