On Thu, Jun 16, 2022 at 03:03:53PM +0200, Geert Hendrickx wrote: > Yes, we see the replica's get an updated contextCSN with SID from the > provider, only the provider itself makes no change to its contextCSN and > stays with the old one, ie. the consumers appear to be ahead of this > provider. So for me, the behaviour of 2.6 and master is still the same as > 2.4/2.5. > > Regarding your fix, you mean the replica (*each* replica?) will increase > the contextCSN for its own SID for this operation? That seems strange to > me, for a failed/refused update on another provider, I would expect no > change at all on the replica's (and esp. the contextCSN associated with > their SID's to never change as long as they receive no updates directly).
Yes, exactly. The accesslog is a DB like any other and you've chosen to add the entries that need an entryCSN of their own. Don't see a way out of that? On a pure replica it's just not involved in replication, on a provider, the accesslog shouldn't stay ahead for long? The NEW_COOKIE message should loop back to it AFAIK, but would need to test that. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
