I'm sorry I haven't gotten back to you on this before now.
I've done some testing and I need a pointer or two to see if I've got something wonky or a bug.
On my master server, the accesslog overlay has a contextCSN value for the accesslog database that has the value of when the slapd was started. It doesn't contain data that far back.
Here's LDIF for the accesslog suffix:
dn: cn=accesslog objectClass: auditContainer cn: accesslog entryCSN: 20070710160157Z#000000#00#000000 structuralObjectClass: auditContainer contextCSN: 20071010225200Z#000000#00#000000
and the oldest information left in the accesslog db has an entryCSN value of 20071022225634Z#000000#00#000000.
First, shouldn't the accesslog db contextCSN be updated to indicate the oldest information still present?
Second, does the syncprov overlay look at the contextCSN of the accesslog db or of the main db? My assumption is it is checking the accesslog db (and hence, doesn't think it needs to send a hint because the accesslog db contextCSN is much older than the contextCSN from the dc=example,dc=com I slapadded on the replica).
Third, I set up a test replica using loglevel any and I do not see any indication that any hint was provided. I've never gone looking for one before -- so, I'm not certain what I'm looking for. However, I see indication that syncrepl initialized and then started feeding in the updates from the accesslog on the master. Did I miss it, is it not logged, or am I just blind again?
Finally, looking at the accesslog.c overlay source, I see where the contextCSN is set from the "main DB" during the original open. However, I have not found any indication that the contextCSN is updated during the subsequent logpurge actions (which may have more to do with I haven't found the code that does the purge action yet than anything else). However, given my current contextCSN in the accesslog db matches the last time slapd was started and the oldest data actually present is from just over 12 hours ago, I'm suspicious.
Thanks,