[Date Prev][Date Next]
Re: (ITS#6469) push replication entryCSN of database suffix out of sync
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6469) push replication entryCSN of database suffix out of sync
- From: firstname.lastname@example.org
- Date: Thu, 15 Apr 2010 10:11:09 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Am Donnerstag 15 April 2010 00:53:04 schrieb email@example.com:
> firstname.lastname@example.org wrote:
> > Am Mittwoch 03 Februar 2010 09:39:19 schrieb email@example.com:
> >> firstname.lastname@example.org wrote:
> >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb email@example.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.