[Date Prev][Date Next]
Re: (ITS#5973) Syncrepl can update more than one csn value
> 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
> 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
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
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.