[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/