There appears to be a long-standing problem with back-bdb and entries with
more than BDB_IDL_DB_MAX immediate children. If the entryIDs of the children
are non-contiguous, then attempts to delete the subtree of the entry will
fail, because the IDL range for the OneLevel index in the dn2id DB will never
back-hdb doesn't have this problem.
Not sure what an appropriate fix is. Ideally, when deleting an entry whose ID
corresponds to either the lower or upper bound of the range, we should update
the range with the ID of the next remaining sibling. But there's no easy way
to search for that ID, so we just increment/decrement the range by 1. The
OneLevel index is the only structure that can quickly tell us what the
siblings are, and it's obviously useless when this situation arises.
The only way to search would be to [inc/dec]rement the ID and retrieve the
corresponding entry's DN to see if it is a sibling of the deleted entry, and
loop until a sibling is found or we run into the opposite range boundary. On a
large DB this will be extremely slow.
Seems like the best fix is to deprecate back-bdb and only use back-hdb from
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/