Ideas wanted for TXN and Concurrent store recovery handling

[Pavel Kankovsky]

On Wed, 28 Jul 2004, Matthias Andree wrote:

> The daemon wouldn't need to spawn children IMO, it can be
> single-threaded to reduce locking contention in the data base, and
> might, after all, eliminate the need for any kills to resolve a deadlock.

Deadlocks can be avoided when you do all updates withing a single
transaction in the predefined order (e.g. lexicographical order of keys).

> My current idea is to have an empty file inside the .bogofilter
> directory that can serve as fcntl anchor (might be DB_CONFIG or the
> wordlist.db file, too, or the directory itself but that may not work
> because some operating systems don't permit write access opens on
> directories which is necessary for fcntl).

This should work...as long as the underlying fs implements fcntl() locks
in a correct way (NFS is infamous for having locking of, ehm, questionable
quality but I don't think BDB itself would work well in such an
environment).

> The remaining question is how does the process know if regular
> or catastrophic recovery is needed?  Neither does harm, but the latter
> can take a whole age or two...

As far as I know, the catastrophic recovery is intended for situations
when db files are lost or corrupted and the database is being rebuilt
from archived snapshots and logs.

Ergo I think the right approach is to run the normal recover and give up
if it fails (alternatively, it might be possible to fail-over to a read
only backup db).

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."