Ticket #47750 - Creating a glue fails if one above level is a conflict or missing;
Ticket #47696 - Large Searches Hang - Possibly entryrdn related
There were multiple issues to break the parent-child relationship when a
When resurrecting a tombstone, there is a possibility that an entry having
the same name was already added. In the case, the code consdered the entry
is already there, which confused the numsubordinates and tombstone-num-
subordinates count. If it is detected, it creates a conflict glue entry
instead of a pure glue entry. The 2 numsubordinates counts were also not
correctly updated in the resurrection case. When the entryrdn was introduced,
Slapi_RDN was held in the entry, which was not correctly updated in the
urp_fixup_rename_entry sets the parent uniqueid if it is a RESURRECT mode
(called from tombstone_to_glue) as being done in urp_fixup_add_entry, which
is necessary to retrieve the correct parent in ldbm_back_modrdn.
. there was a possibility to pass a tombstone DN (nsuniqueid=...,<DN>) is
used to create a glue entry. If found, the part is removed before passing
it to create a glue entry.
. there is a possibility to create a glue entry fails due to the parent entry
not found. This occurs when the parent entry has turned to be a conflict
entry. In the case, instead of retrying the glue creation, it logs an
error and returns.
. turning a tombstone to an ordinary glue entry could fail with the entry
already exists. (Note: ldbm_back_add guarantees that the found entry has
a different nsuniqueid from this tombstone has.) This situation occurs an
entry having the same dn could have been added/replicated by this moment.
And the entry cannot be used for this tombstone to resurrect since the
subordinates/tombstonesubordinates relationships get corrupted. To maintain
the relationship properly, the tombstone is resurrected as a conflict, glue
entry using urp_fixup_rename_entry. If it still returns LDAP_ALREADY_EXISTS,
it is assured the expected glue entry exists since the same nsuniqueid is
. in is_resurect_operation case, a SLAPI_ADD_EXISTING_DN_ENTRY entry and a
SLAPI_ADD_EXISTING_UNIQUEID_ENTRY entry are identical, it returns SUCCESS
instead of LDAP_ALREADY_EXISTS.
. in is_resurect_operation case, the DN is modified from the tombstone DN
to the ordinary DN. The DN is stored in e_sdn as well as in e_srdn in the
Slapi_Entry. The e_srdn part was not updated. This patch fixes it and
e_sdn and e_srdn are in sync.
. parent_update_on_childchange adjusts the count of numsubordinates and
tombstonenumsubordinates. It only took PARENTUPDATE_ADD|_DELETE operations.
This patch adds PARENTUPDATE_RESURECT operation to increment numsubordinates
and decrement tombstonenumsubordinates at the same time.
. in is_resurect_operation case, a tombstone to be replaced with a glue entry
needs to be deleted from the entryrdn index, which was missing.
. Check the target DN if it starts with "nsuniqueid=...,", if it is, log an
error and returns.
. If it is is_resurect_operation case, it allows to rename a tombstone entry.
This is used to support to change a tombstone entry to a conflict glue entry
. ldbm_back_modify checks if the renamed entry has children or not and if
there are, they are updated to point to the renamed entry. The check
function slapi_entry_has_children was just checking the numsubordinates
attribute type. If a positive value is returned, it took care all the
children including the tombstones, but if the renamed entry had tombstoned
children only, it considered there were no children and the tombstoned
children were not updated to point the renamed entry. This patch fixes it.
. Added a flag to entryrdn_rename_subtree and entryrdn_get_subordinates to
treat the given DN a tombstoned DN if it is.
In addition, helper APIs such as slapi_rdn_is_multivalued, slapi_rdn_is_
conflict, and slapi_is_special_rdn are added.
Ported from 389-ds-base-1.2.11.
Reviewed by email@example.com (Thank you, Mark!!)