[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: email@example.com
- Date: Wed, 3 Feb 2010 09:13:02 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Am Mittwoch 03 Februar 2010 09:39:19 schrieb firstname.lastname@example.org:
> email@example.com wrote:
> > Am Dienstag 02 Februar 2010 23:30:23 schrieb firstname.lastname@example.org:
> >> 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.