Logged In: YES 
user_id=226421

We also get this error, though not using Python, but C.  I'm
not sure why people are so eager to dismiss it as an issue
here, however, for it might be something your Python is
doing with the Berkeley DB interface which could be improved.

In our case, there is a similarity -- the site accesses the
database(s) at relatively high frequency, and we use our own
locking system to prevent any conflict (allowing multiple
readers and exclusive writers -- writers not so much as
generating a path to the database, let alone opening it,
until they obtain the separate lock handled by our software).

Periodically one of the databases will have an error when
reading a key, and this error will remain until the database
is repaired.  The error return code is -30987.

It's not 100% conclusive if it happens primarily on
frequently accessed databases or not, and were it the case,
it is not clear whether that's just because it occurs
because of the high volume of access, or just because their
volume increases the likelihood of encountering an error. 
In any case, our locking mechanisms (we've tried more than
one) do lock prior to the database being opened at all, and
are handled in a multi-reader single-writer way.

Again, it's not clear if it's a Berkeley DB problem, or a
problem with the *way* we are accessing/using Berkeley DB. 
Until this is known, I don't think it should be so quickly
blown off that it's not a Python issue -- even if a bit of
resources of the Python resources went into finding a
Berkeley DB problem, would it result in such a bad world?  :)