This isn't a bug per se, but rather something implementors might
want to note:
When initializing OpenLDAP 2.2.17 with a BDB back end yesterday I
was loading several thousand objects into the database from an LDIF
using ldapadd.
I found that after a certain amount of time, I ran into transient
implementation-defined (80) errors adding objects. When I utilized
the -c option to ldapadd, I found that after a few bombed adds these
errors would generally go away and objects would again go in just
fine. An strace revealed a select() timeout was going on under the
hood.
The debug log showed that ldapadd seemed to be timing out waiting
for a lock to get relased in the buffer cache:
slapd[27850]: bdb(dc=carleton,dc=edu): unable to allocate space
from the buffer cache
I tried setting the buffer cache to 500k and found that doing this
alleviated the problem. In DB_CONFIG, e.g., I used:
set_cachesize 0 524288 0
The reason I post here is that normally one wouldn't expect an LDIF
load to cause all the available cache pages to end up being pinned.
I was also surprised to find the default cache size inadequate to
a task like an LDIF load.
As noted, I worked around the problem in question easily. So this
is not a bug report per se.
I'm just hoping that the core developers will find this information
helpful.