[Date Prev][Date Next]
Index corruption (ITS#1650)
This sounds like a bug I have also seen (but not been able to repeat in
a controlled environment). I believe
the bug may be in Net::LDAP! -- The problems went away when I started
producing ldif from my perl-scripts
and used ldapmodify to do the actual ldap operations. I still see the
bug now and again when I have used
Net::LDAP to modify the directory (not just when I have done large
updates, which I no longer do using
Net::LDAP, but even after single updates).
I have never been able to pin this down since I can never be sure which
index will become corrupted. In
"real life" I usually saw corruption for the objectClass index which
might be explained by the fact the in my
case since the bulk updates consists of adding attributes and adding one
or two objectClass values.
My question to the openldap core team is this: Is it worth while to try
to debug this or are you almost done
with your new backend?
PS You don't have do slapcat/slapadd to "fix" the problem. Running
slapindex will work. However make sure
you have no write about to hit the server at the same time you are