160cb3f Ticket #47750 - Creating a glue fails if one above level is a conflict or missing;

Authored and Committed by nhosoi 9 years ago
    Ticket #47750 - Creating a glue fails if one above level is a conflict or missing;
    Ticket #47696 - Large Searches Hang - Possibly entryrdn related
    
    Bug Descriptions:
    There were multiple issues to break the parent-child relationship when a
    resurrect occurred.
    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
    resurrect case.
    
    Fix Descriptions:
    [replication/urp.c]
    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.
    
    [replication/urp_glue.c]
    In create_glue_entry,
    . 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.
    
    [replication/urp_tombstone.c]
    In tombstone_to_glue,
    . 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
      shared.
    
    [slapd/back-ldbm/ldbm_add.c]
    In ldbm_back_add,
    . 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.
    
    [slapd/back-ldbm/ldbm_delete.c]
    . Check the target DN if it starts with "nsuniqueid=...,", if it is, log an
      error and returns.
    
    [slapd/back-ldbm/ldbm_modrdn.c]
    . 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
      in tombstone_to_glue.
    . 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.
    
    [slapd/back-ldbm/ldbm_entryrdn.c]
    . 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.
    
    https://fedorahosted.org/389/ticket/47750
    
    Reviewed by mreynolds@redhat.com (Thank you, Mark!!)
    
        
file modified
+11 -4
file modified
+32 -6
file modified
+100 -8
file modified
+67 -0