[spambayes-dev] Re: [Spambayes] Error from pop3proxy

[Meyer, Tony]

[Tim]
> I'll speculate about one possible problem with Berkeley:  if it isn't 
> shut down cleanly, DBRunRecoveryError may well be an *expected* 
> exception when you next start it, and running recovery at such times 
> would then be a normal part of using Berkeley.  Until we know what's 
> triggering DBRunRecoveryError, I'm just as inclined to believe it 
> can't be fixed without incorporating recovery as I am to believe it's 
> due to a thread race.

According to the sleepcat docs, it's standard practice to check if
recovery needs to be run every time you start up, because nothing can go
wrong if recovery doesn't need to be done and you check.  They say that
it's the db's log files that tell it if recovery needs to be done or
not.  Does the Python wrapper for bsddb reate these log files, too?  If
so, would they be somewhere we can find them and look at them to see if
they indicate what the problem might be?

Also from the docs:
"""
DB_RUNRECOVERY
There exists a class of errors that Berkeley DB considers fatal to an
entire Berkeley DB environment. An example of this type of error is a
corrupted database or a log write failure because the disk is out of
free space. The only way to recover from these failures is to have all
threads of control exit the Berkeley DB environment, run recovery of the
environment, and re-enter Berkeley DB. (It is not strictly necessary
that the processes exit, although that is the only way to recover system
resources, such as file descriptors and memory, allocated by Berkeley
DB.) 

When this type of error is encountered, the error value DB_RUNRECOVERY
is returned. This error can be returned by any Berkeley DB interface.
Once DB_RUNRECOVERY is returned by any interface, it will be returned
from all subsequent Berkeley DB calls made by any threads of control
participating in the environment. 

Optionally, applications may also specify a fatal-error callback
function using the DB_ENV->set_paniccall function. This callback
function will be called with two arguments: a reference to the DB_ENV
structure associated with the environment and the errno value associated
with the underlying error that caused the problem. 

Applications can handle such fatal errors in one of two ways: by
checking for DB_RUNRECOVERY as part of their normal Berkeley DB error
return checking, similarly to DB_LOCK_DEADLOCK or any other error, or by
simply exiting the application when the callback function is called in
applications that have no cleanup processing of their own.
"""

"""
Errors can occur in the Berkeley DB library where the only solution is
to shut down the application and run recovery (for example, if Berkeley
DB is unable to allocate heap memory).
"""

I don't suppose you're low on memory or disk space, are you Richie?  In
any case, the sleepycat docs all seem to say that running recovery will
fix the db without any worries, so perhaps that is simply what we should
do?

=Tony Meyer

(Who wishes that ctrl-c would copy in the new-style html help with
2.3.1)