Transactional Code and Disk Usage

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> I hadn't noticed the db_checkpoint command.  'Tis an additional man page
> to read.  Guess it's time to point my browser at
> /usr/share/doc/db4-utils-4.1.25/utility/index.html and see what's there.
>
> Frankly when I chose to learn about identifying spam I didn't realize
> I'd have to learn the ins and outs of a database system.  Drat :-<

Indeed, this is a complexity. Either you learn that a data base system
can fail (then it's simple) or that it is recoverable from adverse
conditions (then it gets a bit more complex). The bigger background
problem is that checkpoint and archival procedures are _policy_, not
mechanism - and the mechanism is db_checkpoint or db_archive and need to
be reimplemented in bogofilter, only documented.

It's a bit different with bogoutil -f and -F though, because these
require serialization and isolation from bogofilter which db_recover
does not provide.

Does the user want a recoverable data base?
If not, he can run "cd ~/.bogofilter && db_checkpoint -1 && db_archive
-d" to nuke old log files.

How often does the user want his data base checkpointed? Ordinary
recovery only checks from the latest checkpoint onwards to the end of
the log; checkpoints can also be a tuning aid.

>> Common procedure to shrink the logs without data loss (need to be
>> gunzipped manually before a catastrophic recovery):
>> 
>> - cd ~/.bogofilter
>> - db_checkpoint -1
>> - db_archive | xargs gzip -v
>
> Perhaps this should become the db.compact script :-)

Or just documented in a bogofilter manual ("HOWTO") that is to be
written.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)