Full_Name: Rein Tollevik
Version: CVS head + rein-serverID.patch
OS: linux and solaris
Submission from: (NULL) (126.96.36.199)
Submitted by: rein
At startup syncprov searches for any entries with an entryCSN value newer than
the newest contextCSN it read from the db and replaces the newest contextCSN
value with the newest it finds. But the newest entryCSN could have a different
sid field, which would result in the server loosing one valid contextCSN and
instead introduce two contexCSNs with the same sid field. It could also
introduce a defaulted contextCSN with sid=0, which would never be updated unless
there exist a server with that sid, ref my previous ITS.
A patch that fixes this is at the referenced URL. It only updates the
contextCSN from entryCSN values matching the serverID of this server.
My initial thought was that all the contextCSNs that has newer entryCSN values
with the same sid field should be updated. But I'm afraid that could cause
syncrepl to miss some entries if it picks up the updated contextCSN values, as
there may be entries from remote servers with entryCSN values newer than the
contextCSN received from that server. The exception is delta-syncrepl where a
similar update of all the contextCSN values should probably be done at startup.
But that belongs in syncrepl.c if needed, as it is requiered whether syncprov is
used or not.