Wanting a pre-db4 bogofilter

Matthias Andree matthias.andree at gmx.de
Thu Feb 24 23:51:55 CET 2005


Karl Schmidt <karl at xtronics.com> writes:

> I have these ones:
> -rw-r--r--  1 root root 273784 Aug 25 22:32 bogofilter_0.92.6-1_i386.deb
> -rw-r--r--  1 root root 276806 Oct  2 13:17 bogofilter_0.92.7-1_i386.deb
> -rw-r--r--  1 root root 279648 Oct 20 13:02 bogofilter_0.92.8-1_i386.deb
> -rw-r--r--  1 root root 305338 Nov 11 11:02 bogofilter_0.93.1-1_i386.deb
> -rw-r--r--  1 root root 321796 Dec 27 12:32 bogofilter_0.93.3.1-1_i386.deb
> -rw-r--r--  1 root root 359056 Jan 27 12:02 bogofilter_0.93.5-1_i386.deb

The original tarballs are at
<http://prdownloads.sourceforge.net/bogofilter/>

Not too concise, but complete.

> There are a number of different locking methods in data bases that are
> not fully transactional - table locks - row locks etc that would
> probably meet your needs.  A full blown transactional set up is mostly
> used for financial use where both account tables need an entry or not
> - (much like a journaled file system).  InnoDB is used if you are
> doing real accounting transactions in mysql -- you can use Bdb
> storage, but it isn't used much (may be based on the old Bdb - but it
> doesn't look like the new Bdb is a clean design with all these huge
> log files).  I can't see why you couldn't get by with table or row
> locks - do you really need rollback (the reason for the log files)?

Well, MySQL considerations don't apply to bogofilter. PostgreSQL and
SQLite3 exhibit A-C-I-D properties, as does Berkeley DB with
transactional datastore mode. Berkeley DB without transactional mode,
QDBM and TDB only exhibit the I (isolation) property.

bogofilter/bogoutil play dumb and the whole bogofilter or bogoutil
process uses one huge transaction for almost all changes.

The Atomicity trait is helpful as we need to change either all of the
.MSG_COUNT token and the individual tokens or none, for accuracy.

> Just so everyone knows what this is - transactions mean that several
> steps are taken or not taken all enclosed within the "transaction"
> (thus the need to roll back).

That is for the "A" - atomicity - property.

> Sometimes people confuse simple row or table locks with full blown
> transactions. I assume everyone is running on a journaled file system
> these days (jfs seem to be the best bet with 2.6 kernel according to
> recent kernel bugs).

All journaled file systems I know - that is ext3, jfs, logging ufs,
reiserfs, xfs - only journal directory changes, with the notable
exception of ext3 with the non-default (but baseline code) data=journal
mount option.

> Everyone likes what they are used to - and Bdb is thus common - but
> there are other choices out there that may be better for
> bogofilter. There is some information on this in <a
> href="http://www.amazon.com/exec/obidos/ASIN/0596003064/transtronicsinc">
> High Performance MySQL by Jeremy D. Zawodny, Derek J. Balling</a>. He
> talks about the good and bad of several storage engines.

MySQL has several, but none of this has any meaning to bogofilter, which
does not use MySQL.

-- 
Matthias Andree
_______________________________________________
Bogofilter mailing list
Bogofilter at bogofilter.org
http://www.bogofilter.org/mailman/listinfo/bogofilter



More information about the Bogofilter mailing list