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

Re: database destroyed

From: Petr Sebor <petr_at_scssoft.com>
Date: 2002-11-27 03:11:21 CET

>
>
>That makes no sense... the db files *disappear*? Dumping the database
>is just another process that is reading data via libsvn_fs. We should
>have no problem with concurrent db readers. In fact, we expect
>multiple httpd child processes to do this all the time.
>
>
Makes no sense to me as well... I just got this error with a notice
"you have to do DB_RECOVER"... so I did. And even though db_recover
gives me no error, the __db.* files are simply gone. I don't know how
this happened, but it is not for the first time.

>My only thought is that perhaps there is a clash in permissions. That
>is, your 'svnadmin dump' process is running as one user, and the 'svn
>co' process is running as different user. I don't know how this would
>cause db files to vanish, though.
>
>Can you give us a simple reproduction recipe? Just try dumping during
>a checkout? Which process should start first? Which process should
>end first?
>
I will try to verify all of that tommorow. However, the mentioned scenario
is something like this:

checkout at one host
..
.. time passes
..
dumping database begins on localhost
..
.. time passes
..
dump finished
apache2 - internal server error 500
checkout fails with error
__db.* files are gone.... [db_recover is quiet though]

Thats exactly what has happened to me three hours ago. And I remember
the same case happened to me about week ago as well, when doing dump
and update at the same time.

Petr

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 27 03:12:09 2002

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.