https://bugs.openldap.org/show_bug.cgi?id=9823
--- Comment #7 from Ondřej Kuzník ondra@mistotebe.net --- On Thu, Apr 21, 2022 at 12:50:34PM +0000, openldap-its@openldap.org 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.