[email protected] wrote: > On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: >> On 11/19/10 23:55 , [email protected] wrote: >> >>> will evaluate to true in cases where it should not. A quick fix would be to >>> compare directly against the CSN of the sessionlog's head: >> >> An extended version of this fix, which also ensures that the >> sessionlog is kept in csn order, is now in head. Please test, >> syncprov.c revision 1.320. > > Looks good to me. Thank you. > > I discovered this bug while trying to reproduce ITS#6717. > > I've attached a patch to that ITS which appears to fix > that problem. If you have the time, I'd appreciate some > feedback on that patch. The issue makes it very inefficient > to run a slave in refreshOnly mode with a multimaster / > mirrormode master. > > Best Regards,
The current code is broken. > Other than the patch I suggested (using the list head's > CSN value directly), I can think of two other approaches: > > 1) When adding an entry to the sessionlog, check > if sl_mincsn is empty. If it is, update sl_mincsn > to the new entry's CSN. > > 2) When initializing the sessionlog, set sl_mincsn > to the maximum contextCSN value of the underlying > database. > > #2 seems ideal from an efficiency standpoint, although it > differs from the algorithm the current code appears to be > intended to implement. We should have gone with #2. The problem scenario: 1: Provider and consumer in sync, both started fresh, sessionlog is empty. 2: stop consumer 3: write on provider 4: start consumer Result: the sessionlog is ignored, because the sl_head is newer than the consumer's cookie. After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog is used from then on. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
