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

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

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

-------- Original Message --------

Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb

Modified Files:
	operational.c  1.25 -> 1.26

Log Message:
ITS#3470 don't propagate error if hasSubordinates fails, it's not that

CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/operational.c

Changes are generally available on cvs.openldap.org (and CVSweb)
within 30 minutes of being committed.


 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support