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


>> Right; I was slowly figuring it out myself, but I'm also seeing few odd
>> things; for example, after a fresh slapadd -w of a large database dump,
>> which includes entryCSN values, two entries have a CSN newer than
>> contextCSN...  Unfortunately it's confidential data, and it's large (few
>> gigabytes) so it's not something I can easily share, nor is it easy to
>> debug.
> Can you extract just the entryCSNs and attach them to an equal number of
> dummy
> entries to reproduce the situation?

Not now.  However, I think I spotted (and probably fixed) another related
issue.  The key point is that slapadd -w simply checks, and in case
updates, the first occurrence of contextCSN.  I believe this is not
correct: it should go through all occurrences to find if there's one with
the same SID of maxcsn and, if maxcsn is larger than that, update it.  If
none matches, maxcsn should be added.  For this purpose, I defined a
CSNSIDMatch equality rule, that works for the CSN syntax, and allows to
compare CSN values by SID only.  I added this logic to slapadd -w and now
things seem to work as expected.

Another issue I had is that if I need to kill slapd while it's scanning
the whole database with an internal search, there's no way because the
internal search thread is never notified that slapd wants to stop.  So I
added a check for slapd_shutdown in bdb_search where it already checks for
o_abandon.  Note that a shutdown during a regular search will likely
result in setting o_abandon.  But now also internal searches can be
stopped when the server shuts down.  Unfortunately I won't be able to
commit until tomorrow, but I think these two fixes should get into 2.4.5. 
Stay tuned.

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it