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

[Pierangelo Masarati <ando@sys-net.it>]

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...

p.



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