Re: Fw: OpenLDAP Search bug?

[Banzaitron <banzaitron@adelphia.net>]

I have set logging to show everything and the problem is that the candidate
set as you call it is the ENTIRE TREE!!!  It is ignoring my start DN and it
is searching below AND above the DN I pass, regardless of the search scope.
That is why it is taking 4-5 seconds --  it is traversing the entire LDAP
looking for a match for some odd reason.  It does have the sense not to
return matches from anywhere but below the startDN, but why is it wasting 5
seconds searching where it definitely won't find any match?  It should only
be looking below the start DN.

Andy

----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Banzaitron" <banzaitron@adelphia.net>
Cc: <openldap-software@OpenLDAP.org>
Sent: Monday, September 09, 2002 3:26 PM
Subject: Re: Fw: OpenLDAP Search bug?


> At 12:46 PM 2002-09-09, Banzaitron wrote:
> >I tried this with the latest CVS engineering release and the same thing
> >happens.  I have rebuilt the entire database, rebuilt indices, etc and
> >nothing seems to make a difference.
> >Does this sound like a valid bug to open a report on?
>
> Well, it does seem a bit odd.  If you do two search
> operations which only differ by the filters:
>   1.  (&)                        [always TRUE]
>   2.  (objectClass=myorgservice) [depends on entry]
>
> then not only should the set of entries returned by
> the second search be a subset of the entries returned by
> the first search, the candidate set for the second
> search should be a subset of the candidate set of the
> first.
>
> However, both sets of entries may be same (if all
> entries match the filter) and both sets of candidates may
> be the same (if indexing for the second cannot eliminate
> any candidate of the first).
>
> Logging will help you determine the size of the candidate
> sets and to see if they are somehow out of wack.
>
> Kurt
>
>
> >It definitely should
> >not be searching out of the scope I pass it right?
>
> slapd(8) should return entries which don't match your
> search criteria.  slapd(8) uses indexing to avoid
> checking all entries in most cases, but there certainly
> are cases where slapd(8) may need to check all entries,
> including ones which aren't under the baseObject or
> with the specified scope parameter.
>