https://bugs.openldap.org/show_bug.cgi?id=9823
--- Comment #5 from Ondřej Kuzník <[email protected]> --- On Mon, Apr 18, 2022 at 06:49:36PM +0000, [email protected] wrote: > --- Comment #4 from Shawn McKinney <[email protected]> --- > 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. We could teach syncprov about minCSN (as maintained by slapo-accesslog) when nopresent is set but then we should really rename the parameter to something else, more in line with the intended usage. Another thing to keep in mind if we go that route is that minCSN would now have two slightly different uses: - as an indication of how useful the log is as a source of a refresh delete phase - as an indication whether the accesslog is useful as a replication log for deltasync A much tighter set of assumptions is associated with the latter. In general, whenever a main DB runs a plain refresh, this changes what part of the accesslog is usable as a deltasync source[0] while its usefulness to serve as a sessionlog source is unaffected. [0]. A plain refresh destroys ordering information so anything before it has finished is suspect for deltasync. Currently we ignore that, see ITS#9580 for more background -- You are receiving this mail because: You are on the CC list for the issue.
