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

Re: [Fwd: commit: ldap/servers/slapd/back-bdb operational.c]

Howard Chu wrote:

This may not be the best fix... The problem was with the entry being added getting passed to send_search_entry for the persistent search, which calls backend_operational. When the syncrepl consumer is configured to retrieve operational attributes, this results in bdb_hasSubordinates being invoked. bdb_hasSubordinates returns LDAP_OTHER if the entry's e_private pointer is NULL. Since the syncprov overlay is passing the original Add entry (and not the cached copy of it) in, its e_private pointer is NULL, so this caused backend_operational to return the LDAP_OTHER failure, so send_search_entry didn't send anything.

Perhaps it would be better to relax the test in bdb_hasSubordinates to just ignore the entry and return Success in this situation. ??

Relaxing the test should be fine, because the hasSubordinate is simply supposed to provide a hint as whether the entry has subordinates or not, it's not supposed to be authoritative or consistent or so. In principle, when the e_private member is NULL, bdb_hasSubordinates() could try and look for the entry in the cache and check if it has any children, but I wouldn't go that far; also consider the chance of deadlocking somewhere along the path...


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497