Re: (ITS#6469) push replication entryCSN of database suffix out of sync

[rhafer@suse.de]

Am Donnerstag 15 April 2010 00:53:04 schrieb hyc@symas.com:
> rhafer@suse.de wrote:
> > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc@symas.com:
> >> rhafer@suse.de wrote:
> >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc@symas.com:
> >>>> But how did the suffix entry get created without an entryCSN in
> >>>> the first place? The MOD that updates the contextCSN doesn't
> >>>> happen until after the suffix entry already exists.
> >>> 
> >>> It wasn't created without an entryCSN. It always had one. But the
> >>> MOD to update the contextCSN (coming from the provider) doesn't
> >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add
> >>> entryCSN to the MOD operation. The easiest fix is probably to
> >>> never touch the opattrs if "updatedn" is doing MODs, though I am
> >>> not yet sure if it might break something. Currently my fix (not
> >>> committed yet) only skips the slap_mods_opattrs()  step if
> >>> "updatedn" it is doing a MOD on contextCSN.
> >> 
> >> Ah, got it. Yes, sounds like your fix is fine.
> > 
> > Do you think it's fine to always skip slap_mods_opattrs() if
> > "updatedn" is writing? Or should I check for contextCSN MODs
> > specifically?
> > 
> >> Historically the updatedn user (e.g. slurpd) has always provided
> >> all of the operational attributes in its updates.
> 
> I guess the question is what have we done in the past for updatedn
> writes? If we filled in missing opattrs, then we should continue to
> do so. So it should be a special case for contextCSN mods.
Ok, that's how the current fix work. So I think we are fine here now.

-- 
Ralf