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

Re: latest status

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-08-29 22:58:28 CEST

On Wed, Aug 29, 2001 at 12:56:20PM +0200, Sander Striker wrote:
> > On Tue, Aug 28, 2001 at 09:44:43PM -0700, Greg Stein wrote:
> > Thus: simultaneous access is causing DB_INCOMPLETE (not a surprise, given
> > the Berkeley docs), the DB_INCOMPLETE is messing up our close, and we are
> > leaking.
> Yes, that is what is happening. The svn_fs_close_fs ends up calling
> cleanup_fs_apr (via the apr_pool_destroy of the fs pool). This in turn
> calls cleanup_fs. This call has a series of SVN_ERR wrapped db->close
> calls. Ofcourse when another thread is writing to the db DB_INCOMPLETE
> is returned and cleanup_fs bails out.


> The docs state DB_INCOMPLETE can be safely ignored in db->close and
> db->sync. These urls might be helpfull (and important regarding corruption/
> recovery):
> http://www.sleepycat.com/docs/ref/program/errorret.html#DB_INCOMPLETE
> http://www.sleepycat.com/docs/api_c/db_close.html

Seen 'em long ago :-)

> With this in mind there are 2 solutions for the problem. The first is
> to tell the db not to flush (so no DB_INCOMPLETE can occur). The second
> is _try_ to flush but ignore DB_INCOMPLETE when flushing doesn't work.

We'll take the second. We do use transactions, so even if we didn't sync, we
wouldn't lose any information in the event of a crash. However, recovery
will be easier if we try to sync changes.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006

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