[Date Prev][Date Next]
Re: Corrupt index files
Darren Gamble wrote:
> Good day,
> Thanks for the rapid reply.
> > That was probably me. I installed Berkeley DB 3.3.11 (now in Red Hat
> > 7.3) and rebuilt the source RPM for openldap-2.0.21 after removing the
> > "--with-ldap-api=gdbm" configure directive. It then uses Berkeley DB
> > automatically.
> That sounds familiar. Just a clarification... what is the actual source of
> the problem? Is it the version of the backend, how 2.0.21 uses the backend,
> how 2.0.21 uses gdbm in the backend, etc?
If you find out, let me know. I just know that since switching
databases I haven't heard any complaints.
> As I sort of understand things, the problem is how 2.0.21 uses gdbm. I
> _think_ that it's been fixed in a newer version of the server, but I recall
> you (or whomever it was) saying something like "that version uses ldbm just
> fine and ldbm is a much better backend anyway". Is this correct?
Ldbm works with either Berkeley DB or GDBM. Ldbm is _currently_ more
stable than the bdb backend which requires Berkeley DB. Bdb makes use
of the fine-grained locking available in Berkeley DB for concurrent
updates whereas ldbm has a single write lock (and that only since
2.0.22). The lack of write locking can cause index corruption and is
probably what you're remembering as having been fixed. However, I've
had index corruptions with GDBM that wouldn't go away after a slapindex
or even after a dump and restore of the database.