[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: Wed, 14 Apr 2010 22:53:04 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/