Re: (ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB

[hyc@symas.com]

Rein Tollevik wrote:
> On Tue, 18 Mar 2008, Howard Chu wrote:
>
>> rein@basefarm.no wrote:
>>> syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe
>>> (assigned to op->o_bd).
>> Yes.
>>
>>> In a subordinate database this is the parent DB, it
>>> should be written to the suffix of si->si_be instead as the attached patch
>>> fixes.
>> No. It works as designed.
>
> Hm, that sounds as a bit odd design to me.  I find it most natural that
> the contextCSN should be stored in the suffix of the backendDB where
> syncrepl is used.  Then it doesn't interfere with the contextCSN of
> other neighboring databases replicated below the same common superior,
> nor with the contextCSN a syncprov overlay on the superior glue database
> maintains.  But I will not claim to have understood more than a tiny
> fraction of the syncrepl protocol and code, so I might be complete lost
> on this one.  If I'm wrong this raises a few other questions though.

> Upon startup syncrepl reads (in do_syncrep1()) its initial contextCSN
> value from the suffix of the backend where it is used.  If it is correct
> that it in a glue'ed environment should write it to the suffix of the
> superior glue DB, shouldn't it be read from there as well?

Yes. This code is still being reworked.

> My experience from the 2.4.8 release is that syncrepl and syncprov tends
> to interfere with each other when they both try to maintain the
> contextCSN of the same backend DB.  I.e if they are both used on the
> same database or if syncrepl writes its contextCSN to the suffix of a
> superior glue database where syncprov is used.  I realize that using
> both on the same backend may be necessary in many configurations, but
> luckily we was able to avoid it.  I see that the syncrepl code that uses
> delete/add to update the attribute (which would fail after syncprov has
> replaced all values) has been rewritten in cvs, so I guess this would
> not be a problem in an upcoming release.

That's ITS#5426. It's also one of the reasons that our contributing guidelines 
state that you should submit patches against HEAD, not the released code. 
These fixes will be in 2.4.9 but it's likely that the patches you've created 
against 2.4.8 are already obsolete.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/