[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.
Kurt