[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Regression in bindings? 1.7/1.8 vs 1.6

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 14 Aug 2014 00:24:09 +0200

On Wed, Aug 13, 2014 at 12:32 PM, Philip Martin <philip.martin_at_wandisco.com>

> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> > The solution seems to be to simply destroy the txn_dir_cache
> > instance at the begin of the commit. That comes at some extra
> > cost but that is still proportional to the size of the commit.
> There would be no cost to mod_dav_svn since the txn_dir_cache is already
> NULL when handling MERGE. There would be a cost to svn:// and file://.
> > The only sequence that would get us into real trouble is
> >
> > thread / process A: modify txn
> > thread / process B: modify txn
> > thread / process A: modify txn (via same fs_t as before)
> >
> > Since A won't re-read the directory contents and may therefore
> > return "path not found" errors or miss earlier modifications to a
> > given node / sub-tree and use a new copy for the following mods.
> > But I guess we don't support that sequence at all.
> We don't support it right now because it doesn't work, but do we want it
> to work? fs-test 44 is the new test I wrote: it FAILS for FSFS but is a
> PASS for BDB and FSX. It is also a PASS for 1.6 FSFS.

Hm. Right now, we haven't changed the on-disk representation
of in-txn directories. It is still append-only. So, we could cache
the directory file size along with the contents and use that for
an OOD check.

I wouldn't want to do it for 1.9 but it is certainly an option later.
The driver behind this would be concurrent puts.

-- Stefan^2.
Received on 2014-08-14 00:24:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.