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

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node



> It's not clear to me where the issue is.  What is the "right" sequence the
> add of the new superior and the mordrdn should be transmitted?  Should the
> provider operate differently, or should the consumer check all syncrepl
> messages and try to rebuild the final state, instead of giving up when the
> internal lookup for the newsuperior fails?  Probably, a workaround could
> be to perform the modrdn by crating the new superior as a glue object,
> which eventually will be replaced by the actual add.

I've quickly hacked things this way, and it seems to work fine.

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.1.patch>

Please let me know if this approach is sound enough, I might have
overlooked some implications.

p.