[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: index corruption (1164) still present in 2.0.15 with db 3.1.17 (ITS#1359)

At 08:41 AM 2001-10-01, Leif Johansson wrote:
>I have bad news. The problem still appears using gdbm. I theorize that
>the fact that objectClass is modified when the bug appears is material.
>Maybe the index just gets too big...??? In any case I will try again
>tomorrow with db3.3.11.

First, I've disabled BerkeleyDB CDB in OPENLDAP_REL_ENG_2 because
I do not have high confidence in it.  The previous code make have
actually been correct.  I'll likely reintroduce this as an
elective feature in a later version.

This means that we are serializing access to both GDBM and
BerkeleyDB.  We should be able to replace the mutex with a
reader/writer lock when BerkeleyDB DB_THREAD has been used.
This can be introduced as an elective feature in a later version.

Assuming (possibly incorrectly) we've identified and fixed all
the other bugs in slapd, this leaves us with the transactional
issue inherit in the design of back-ldbm.  This is being addressed
in the back-bdb development (which is slow going due to resource
constraints, e.g. my time.  Help is welcomed).

However, as it there might be other problems with back-ldbm,
I ask that those who are having reproducible corruption problems
test HEAD built w/ -DLDBM_DEBUG_IDL=1.  (I'll commit this debug
code to OPENLDAP_REL_ENG_2 soon.)  This code checks index ID lists
for consistency.