[Date Prev][Date Next]
Re: SQL backend SELECT problem (1=1 causes horrible performance)
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:
(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:
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
Sorry for asking, but I am no OpenLDAP core guru;
Is the "attributes to load" in the above examples what you are referring
Thank you very much