Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein

Scenario: A syncrepl consumer replicates a backend DB where it has at least one entry that is up to date when it starts, but there are newer entries on the producer. The oldest contextCSN presented by the consumer is older than all entryCSN values in the replicated backend on the producer..

When syncprov_findcsn() is called with the FIND_CSN tag it will not find any entries whose entryCSN is <= the oldest csn presented by the consumer, and the cookie set will be determined as stale. Which again means that no present UUIDs will be sent to the consumer.

The producer will, during the search that follows, skip sending entries whose entryCSN values are older or equal to a contextCSN with the same sid presented by the client. I.e the consumer will neither get these entries in a present UUID set nor as updated entries, and will therefore incorrectly remove them from its database.

A fix that seems to solve this is that syncprov_findbase(FIND_CSN) should search for entries whose entryCSN value is less than the largest contextCSN presented by the client. All the test scripts succeed if I try this, but I'm not convinced that this is the correct fix. Would it not be more correct to ignore the entire CSN set presented by the consumer when it has been determined as stale?

Hm, if the oldest contextCSN is from a server that is seldom updated this alternate fix could mean that a full reload would be performed every time the client starts with an outdated contextCSN set. Would the best fix be to do both, i.e search for entryCSN <= the largest csn presented by the client, and also ignore the csn set when it has been determined as stale?

Rein Tollevik Basefarm AS