It never fails (bsddb retirement in 2.3)

[eichin at metacarta.com]

> If the problems are indeed keyed to the size of the database, I can
> understand why the problem is rarely observed with password databases
> and the like.

If my (woefully dusty) memories of the "version of Berkeley DB shipped
with Kerberos V5" are accurate (this was "near" 1.85 but not exactly,
as well) that the issue wasn't *strictly* size, but more related to
number of "similar" keys, ie. things that made hash-bucket-chains grow
instead of going into distinct ones.  There were return-value issues
that led certain overflow cases to corrupt the DB altogether.  The bug
was inherited somewhat from the dbm design - I seem to recall a test
case that could "break" a dbm database in 10 to 30 STOREs, if you knew
the right things about chosing your own keys... and yes, it was based
on a Real Customer Problem(tm).

Oddly enough, the solution we (at Cygnus, not MIT, back in the
"KerbNet" days) took was to switch from HASH mode to BTREE
mode... because BTREE tested out to be much more reliable *and*
significantly faster, for the particular load a krb5 kdc database was
likely to present (not a "normal" one, we were actually testing with
over a million "usernames".)  I'm not sure that particular flag is
exposed in the APIs at use here, though.  And I'm reasonably sure that
the *BSD platforms have fixes for everything we found, even if they
are still using HASH mode...