On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote: > It's becoming untenable how a plain refresh cannot be represented in > accesslog in a way that's capable of serving a deltasync session. > Whatever happens, we have lost a fair amount of information to run a > proper deltasync yet if we don't want to abandon this functionality, we > have to try and fill some in.
Continuing with the theme, proposal 4 is analogous with the earlier one, but the onus is on the consumer. The provider still notifies its accesslog of entering (and potentially exiting) a plain refresh on the replicated DB. A delta consumer processing this entry will note this down into its own accesslog and transition into a fallback state. That state is in many ways a plain style refresh, other outbound sessions are abandoned, but we keep reading the accesslog, processing these regardless of their CSN, not committing the cookie either. This leaves the same issue of getting out as proposal 3, with the complication that we could still be in a persist phase when this happens and end up in a circular stalemate of everyone being in this zombie state. Again we need to be able to guarantee this won't linger as it could isolate a subset of the environment from the rest. Another issue is that we would have introduced a new mode into the protocol, something between plain and delta syncrepl and that would need to be properly understood. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
