I'm seeing it multiple-valued in some bulk testing I'm doing; does it make any sense? Its specification, in schema_prep.c, doesn't explicitly set the SINGLE-VALUE constraint.
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 ---------------------------------------
Pierangelo Masarati wrote:
I'm seeing it multiple-valued in some bulk testing I'm doing; does it make any sense? Its specification, in schema_prep.c, doesn't explicitly set the SINGLE-VALUE constraint.
It will have multiple values in multimaster replication.
Pierangelo Masarati wrote:
I'm seeing it multiple-valued in some bulk testing I'm doing; does it make any sense? Its specification, in schema_prep.c, doesn't explicitly set the SINGLE-VALUE constraint.
It will have multiple values in multimaster replication.
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.
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 ---------------------------------------
Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
I'm seeing it multiple-valued in some bulk testing I'm doing; does it make any sense? Its specification, in schema_prep.c, doesn't explicitly set the SINGLE-VALUE constraint.
It will have multiple values in multimaster replication.
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?
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 ---------------------------------------
Pierangelo Masarati wrote:
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.
Just for the records: http://www.openldap.org/faq/data/cache/1145.html
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 ---------------------------------------
Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
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.
Just for the records: http://www.openldap.org/faq/data/cache/1145.html
draft-chu-ldap-csn was somewhat off base to begin with; it was an attempt to define a new format without the useless changeCount field that we're currently carrying around. Note that liblutil/csn.c documents the actual format and its original source (draft-ietf-ldup-model-03.txt) and also the change of the server ID field from 2 to 3 hex digits.
-
Howard Chu -
Pierangelo Masarati