Re: SQL backend SELECT problem (1=1 causes horrible performance)

[Jakob Oestergaard <joe@sysorb.com>]

Hello Pierangelo,

Thank you very much for your quick reply!

...
> > Is this correct?  Or are the "OR 1=1" clauses generated elsewhere?
>
> If you're using OpenLDAP 2.3 that's correct.  Previous versions
> always used '1=1' to indicate TRUE.

I'm using 2.2.23 (from Debian Sarge)

Does this mean I could be in luck and that the 1=1 could be from 
something else?  :)

>
> The bottom line for a search whose filter contains extended match
> with the "dn" field set consists in searching the entire database. 
> It would be interesting to see what request gets to slapd.  Can you
> provide logs of the server at "stats" level?


The search reported by slapd -d 1 is:
==>backsql_search(): base="ou=contacts,dc=evalesco,dc=com",
 filter="(|(mail=*foo@*)(displayName=*foo@*)(givenName=*foo@*)
         (sn=*foo@*))", scope=2, deref=0, attrsonly=0,
 attributes to load: custom list

If I submit a slightly simpler query using ldapsearch, I get the correct 
simple SQL statement produced, and slapd -d 1 reports:

==>backsql_search(): base="ou=contacts,dc=evalesco,dc=com",
 filter="(mail=elite@*)", scope=2, deref=0, attrsonly=0,
 attributes to load: all

The obvious difference between the two, being that Thunderbird submits a 
"custom list" of attributes to load, while my ldapsearch just requests 
everything.  Could that difference cause 1=1 to be inserted?

...
>
> Well, you could hack back-meta to ignore the "dn" bit of extended
> matches; or, you could write an overlay that strips it from search
> filters.

Sorry for asking, but I am no OpenLDAP core guru;
Is the "attributes to load" in the above examples what you are referring 
to here?

Thank you very much

-- 
Best regards,
   Jakob Oestergaard