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

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



Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc@symas.com:
> ralf@OpenLDAP.org wrote:
> > Full_Name: Ralf Haferkamp
> > Version: RE24, HEAD
> > OS:
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (89.166.208.247)
> > Submitted by: ralf
> > 
> > 
> > When using push-based replication (syncrepl-proxy) the entryCSN of
> > the consumer's server's suffix entry (the one that also holds the
> > contextCSN Attribute) is not in sync with the value on the
> > provider. (Other operational Attributes are out of sync as well)
> > 
> > This is because the MOD Operation to update the contextCSN (sent by
> > the provider) does not contain any other operational Attributes.
> > That causes the consumer to add those attributes itself.
> > 
> > I guess the problem is mostly cosmetic, but I'll submit a fix
> > anyway. (not calling slap_mods_opattrs() if the updatedn modifies
> > "contextCSN")
> 
> 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.

-- 
Ralf