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?

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.

Rein