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 http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------