On 13.01.11 21.31, hyc@symas.com wrote:
cmikk@qwest.net wrote:
On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote:
On 11/19/10 23:55 , cmikk@qwest.net 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.
Which current code? My patch for this its, or his patch for its#6717?
Other than the patch I suggested (using the list head's CSN value directly), I can think of two other approaches:
- 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.
- 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.
Initializing sl_mincsn from the maximum csn won't do much good here, as long as the (current) requirement to use the log is that the consumers mincsn is greater or equal to sl_mincsn. Assuming there is more than one csn in the set that is..
Initializing with the minimum csn should cause the current log to be used in this scenario. But, if the provider restarts between 3 and 4 it would incorrectly appear that replaying the log would be sufficient to bring the consumer in sync. A situation far worse than doing a refresh when replaying the log would have been sufficient.
More on possible fixes in my reply to your other message.
Rein
-
rein＠OpenLDAP.org