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