[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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.