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.