We might be able to add code to back-bdb to check for the existence of a
DB_CONFIG file in the DB directory, and create one if it's not present.
But (aside from the locking issues we already have, re: multiple processes
accessing the BDB environment at once) we have no way to determine any
meaningful default values for the BDB cache size. That is entirely
dependent on the ultimate size of the database, as constrained by the
amount of free physical memory in the machine. We might arbitrarily
examine the system and allocate 50% of free memory, but there's no
portable mechanism for determining that size. We also cannot arbitrarily
use this much memory without taking into account whether other database
instances are also being configured.

It is very easy for the sysadmin to determine these parameters. It is very
hard for the code to do so by itself. We have left it as the sysadmin's
responsibility to get this right so far, and I believe that's the correct
path, but I'm interested in hearing any other suggestions.

Howard,

I have to agree, working here at Stanford as a Sys Admin, that it is
particularly impossible to set these parameters in advance. It really
depends on how a system is being used. I think what is useful here though,
is the writeup you just listed above. Now, I will be putting stuff like
this into the pages I'm writing about Stanford's OpenLDAP setup, but it
might be useful to have a very small discussion of ways to determine how to
set up DB_CONFIG in the back-bdb man page.