[Date Prev][Date Next]
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