https://bugs.openldap.org/show_bug.cgi?id=9823
--- Comment #7 from Ondřej Kuzník <[email protected]> --- On Thu, Apr 21, 2022 at 12:50:34PM +0000, [email protected] wrote: > 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. This is false, imagine a multi-sid environment, provider in question is A, other providers include B and C: - replica X disconnects - sid B and C recieve new write operations - sid B operations reach A in a timely manner - sid C CSNs are significantly delayed in reaching A - logpurge kicks in purging some sid B operations (sid C operations older than these are retained) - replica X reconnects to A, sid C csn is chosed as the older CSN for some reason, it is found in accesslog, replication continues (with the same effect as decscribed in this issue) I agree nopresent is important for efficient deltasync operation. Just suggested there is no other use of this configuration option than on a logDB and we can conflate this in a proposed behavioural change. -- You are receiving this mail because: You are on the CC list for the issue.
