--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Ondřej Kuzník from comment #5)
On Mon, Apr 18, 2022 at 06:49:36PM +0000, openldap-its(a)openldap.org
> --- Comment #4 from Shawn McKinney <smckinney(a)symas.com> ---
> The question, why doesn't it fallback into plain sync repl? Or, given some
> indication to the consumer (error) that it can't be brought back in sync, i.e.
> dsync has occurred.
Syncprov just lets the consumer replicate the current contents of the
database (minus any deletions because syncprov-nopresent is set). It has
no idea that deletes happened (there is no record of them) and how it
all fits into the semantics of delta-syncrepl.
Deletes are irrelevant when polling the log. The log is a queue, appends at the
tail and deletes from the head. The only check that's required is to see if the
consumer's cookieCSNs are still present in the log. If not, then records that
cover the cookie are gone, and a refresh from the mainDB is needed. That's why
we use the nopresent config on the logDB, because a normal present phase is a
bunch of work for no extra benefit.
You are receiving this mail because:
You are on the CC list for the issue.