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

Re: Issue in syncprov findcsn code

Rein Tollevik wrote:
Pierangelo Masarati wrote:

Not sure this is a bug, but I'm curious... I hit this while checking for
ITS#5661.  The code below is from HEAD's syncprov.c:613 (not changed
recently; pardon any unintended line wrapping):

[code and discussion removed]

- make syncprov_findcsn() search the newest contextCSN instead of the
one with its SID

Only looking for contextCSN values with sid matching the serverID was introduced in revision 1.240 to fix ITS#5537.

- initialize slapd_serverID with some SID_UNDEFINED in order to take the
action above only when SID is not defined

I agree, although I would prefer to take it one step further and reserve serverID==0 for the tools case. In ITS#5536 I tried to distinguish between a defaulted and configured serverID==0, but it didn't quite slip through and was closed without being properly fixed. It should probably be reopened.

Well, a serverID of 0 is basically the same as no serverID. For mirrormode/multimaster the serverID must be non-zero. For single-master the serverID must be zero.

By the way, re: the current test050 failures in RE24, I saw the failure occur again even with the latest syncrepl.c patch reverted, so it appears that was just coincidental the last time.

Btw, the ITS#5675 fix to syncrepl.c improves the contextCSN propagation
from syncrepl to syncprov, but the csn queue isn't really suitable for
that.  Syncrepl may update more than one contextCSN value at the same
time, but the queue can only pass one around.  I'm currently testing a
patch that fixes the contextCSN propagation problems we have seen, it
should fix this as well.

-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/