Is using Berkeley DB 4.0.14 recommended?

[Mark Keasling]

Hi,

On Thu, 17 Oct 2002 09:10:44 -0400 (EDT), Rob Siemborski <rjs3 at andrew.cmu.edu> wrote...
> On Thu, 17 Oct 2002, Mark Keasling wrote:
> 
> > I'm trying to use Berkeley DB 4.0.14 and am getting the dreaded
> >   DBERROR db4: 4 lockers
> > messages even when only starting up the master process.  From
> > what I've seen reported, the lockers number will only increase and
> > cyrus will eventually start failing.
> 
> DB4.0 has a known (cosmetic) bug that causes this number to monotonicly
> increase (they apparently are missing a decrement).  So as long as it is
> only increasing at a slow rate and you aren't seeing any other problems,
> all is well with the world.
> 
> I don't believe any recent version of cyrus has a major Berkeley DB
> locking problem.  Of course, we also recommend using the skiplist backend
> for the mailboxes.db file.

Rob, thank you for this information.

My database configuration is currently:
	--with-duplicate-db=db3_nosync
	--with-mailbox-db=db3
	--with-seen-db=flat
	--with-subs-db=flat
	--with-tls-db=db3_nosync

I'll change the configuration for mailboxes.db from the default db3
to the recommended skiplist.

There is a need to know the extent to which the lockers bug will require
administrative involvement.  I'm planning to install cyrus but won't
be the entity administrating it.  I need to know in advance what
problems (may | will) be encountered and what has to be done to correct
them.  Ideally after installation the only administration required would
be user additions and deletions.

Please bear with the innumberable dumb questions...

The duplicate and tls databases are configured as db3_nosync.  Will
these also exhibit the lockers problem?  (The error message doesn't
indicate which database is having the lockers problem.)

What problems occur with the lockers values reaches the max value?

Is it possible to use a different type of database?  (ie, gdbm,ndbm)
Since they aren't used, most probably they can't be.

Has anyone tried to figure out what circumstance(s) causes the lockers
value to not be decremented?  or what may be done to inhibit interminal
incrementation?  (ie a s{i,a}mple program that exhibits the lockers problem)

Has anyone looked at the database code in an attempt to determine were
the bug is?  (Does anyone have that much free time?)

Are there any actions that "reset" the lockers value?  Or is it permanent.
Once the value reaches the max, you have to throw away the database and
start over?  Is is possible to dump and rebuild the database(s)?

Can the database recovery be automated?

At what frequency would the lockers value reach the maximum (under
ordinary conditions (someone reported weekly)) and administrative action
be required?  Once every ten years isn't really much to worry about; but
once a week is ridiculus.  I'd say that more than once a year may be
considered excessive.

Is there a way to determine what the lockers value is so that an
estimated time to failure can calculated?  If the failure time can
be determined in advance, maintenance can be scheduled before hand
rather than having an "emergency" were the system unexpectedly fails
and must be fixed immediately.

Regards,
Mark Keasling <mark at air.co.jp>