From d606691d341dfffee0b02fc55fb29f74f975e775 Mon Sep 17 00:00:00 2001 From: Thierry Bordaz Date: Wed, 21 Mar 2018 18:26:16 +0100 Subject: [PATCH] Ticket 49619 - adjustment of csn_generator can fail so next generated csn can be equal to the most recent one received Bug Description: On consumer side csn_generator ajustment occurs (let CSN = highest known csn) when a replication session starts when a csn is generated locally and than csn is <= CSN During adjustment, in the case there is no remote/local offset (time change) the current_time on the consumer is identical to CSN Then next locally generated csn will only differ with seqnum The seqnum of the csn_generator is increased only if CSN.seqnum is larger than the csn_generator one. In case of egality, it remains unchanged. The consequence is that the next locally generated csn will be identical to CSN (except for the RID). So even after csn_generator adjustment, csn_generator may create csn that are not larger than the CSN Fix Description: compare the new generated timestamp (time+offsets) with adjustment one. If the new is greater or EQUAL, make sure the local seqnum is ahead the remote one https://pagure.io/389-ds-base/issue/49619 Reviewed by: Mark Reynolds Platforms tested: F27 Flag Day: no Doc impact: no --- ldap/servers/slapd/csngen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ldap/servers/slapd/csngen.c b/ldap/servers/slapd/csngen.c index 287ea847e..4ac45acf0 100644 --- a/ldap/servers/slapd/csngen.c +++ b/ldap/servers/slapd/csngen.c @@ -331,7 +331,7 @@ csngen_adjust_time(CSNGen *gen, const CSN *csn) /* let's revisit the seq num - if the new time is > the old tiem, we should reset the seq number to remote + 1 if this won't cause a wrap around */ - if (new_time > cur_time) { + if (new_time >= cur_time) { /* just set seq_num regardless of whether the current one is < or > than the remote one - the goal of this function is to make sure we generate CSNs > the remote CSN - if -- 2.13.6