Re: (ITS#5973) Syncrepl can update more than one csn value

[rein@OpenLDAP.org]

hyc@symas.com wrote:
> rein@OpenLDAP.org wrote:
>> Syncrepl can update more than one csn value in one operation, but only one can
>> be passed to syncprov in the csn queue.  Syncprov should instead pick the
>> updated values from the modify operation.

> The syncrepl patch broke the CSN queue, which has caused out-of-order updates 
> in test050. I have reverted it. Every write operation begins with a queued CSN 
> and ends by graduating a CSN. You removed the enqueueing step, and so the 
> queue contents were invalid.

I removed the queuing and graduating of the CSN syncrepl_updateCookie() 
would update, as that only sent one of the (possibly) many values that 
could be updated by that operation.  With the syncprov half of the patch 
the queued patch should never be looked at, meaning that this queuing 
should be unnecessary here.

The ordinary queue/graduation of the CSN received with an updated entry 
is still in place, and should continue to be so.

>> A patch that fixes this is coming.  This patch depends on the ITS#5972 patch,
>> and is required for the new test058 to succeed.
> 
> test058 has the same number of errors with or without the syncrepl patch, so I 
> don't think it was relevant to the issues you were addressing.

It was only the syncprov half of ITS#5793 patch that was relevant for 
test058.  The syncrepl half of the patch only removes code that should 
be unnecessary..

> I'm still skeptical about the syncprov half of the patch. The two patches were 
> actually unrelated, the syncprov patch takes effect regardless of the syncrepl 
> patch.

Yes, the syncprov part of the patch doesn't need the syncrepl half, but 
I found it correct to clean up code that should be made unnecessary by 
that patch.

All updates received during the persistent phase should include an 
updated CSN value, and should already have been transmitted to syncprov 
by the commit/graduate queue and have caused it to update its own csn 
set.  I.e, the syncrepl_updateCookie() replace operation should only 
have caused syncprov to updated its cookie and thereby send NEW_COOKIE 
messages when syncrepl updated the CSN set at the end of the refresh 
phase.  Apparently, there is something that causes this to break.  More 
on that in another message on -devel.

Rein