(ITS#5564) Use largest contextCSN to determine staleness?

[rein@OpenLDAP.org]

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