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

inequality search error

FC4, BDB 4.2.52 + patches, Openldap 2.3.4

I've tested all my apps, and they work great with 2.3 except the one with the inequality searches (my problem child). I'll say up front that I do understand there is no inequality indexing support for integer syntax attributes in OpenLDAP. However, this app worked fine on 2.2.23 and was plenty fast despite the brute force algorithm.

I've got just under 4000 entries with an attribute as defined by:

attributetype ( 1.3.6.1.4.1.15121.2.5.3 NAME 'gospqualifier'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

It's indexed for eq, and when I try:

ldapsearch -x -b ou=Gospel,ou=Expressions,o=mentata.com "(gospqualifier=400503)"

I get the matching entry in a blink. Same for values 400504 through 400512. However, when I try:

ldapsearch -x -b ou=Gospel,ou=Expressions,o=mentata.com "(&(gospqualifier>=400503)(gospqualifier<=400512))"

I get nothing. This failure seems to be random, because if I do, say:

ldapsearch -x -b ou=Gospel,ou=Expressions,o=mentata.com "(&(gospqualifier>=421324)(gospqualifier<=421325))"

I immediately get the two entries where gospqualifer=421324 and gospqualifier=421325.

When I turn logging on (loglevel 45) and examine the logs, I find the two inequality filters used above record the same general pattern of operations, but then after *many* bits like:

Aug  3 10:09:37 www slapd[2864]: bdb_idl_fetch_key: [086cacfb]
Aug  3 10:09:37 www slapd[2864]: <= bdb_index_read 1 candidates
Aug  3 10:09:37 www slapd[2864]: => key_read

on the failed request I see:

Aug 3 10:09:37 www slapd[2864]: bdb_idl_fetch_key: [086cacfb]
Aug 3 10:09:37 www slapd[2864]: <= bdb_index_read: failed (-30990)
Aug 3 10:09:37 www slapd[2864]: <= bdb_inequality_candidates: id=138, first=876, last=4920
Aug 3 10:09:37 www slapd[2864]: <= bdb_filter_candidates: id=138 first=876 last=4920
Aug 3 10:09:37 www slapd[2864]: <= bdb_list_candidates: id=0 first=942 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_filter_candidates: id=0 first=942 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_list_candidates: id=0 first=0 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_filter_candidates: id=0 first=0 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_list_candidates: id=0 first=0 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_filter_candidates: id=0 first=0 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_list_candidates: id=0 first=850 last=0
Aug 3 10:09:37 www slapd[2864]: <= bdb_filter_candidates: id=0 first=850 last=0
Aug 3 10:09:37 www slapd[2864]: bdb_search_candidates: id=0 first=850 last=0
Aug 3 10:09:37 www slapd[2864]: bdb_search: no candidates
Aug 3 10:09:37 www slapd[2864]: send_ldap_result: conn=0 op=10 p=3
Aug 3 10:09:37 www slapd[2864]: send_ldap_result: err=0 matched="" text=""
Aug 3 10:09:37 www slapd[2864]: send_ldap_response: msgid=11 tag=101 err=0

while on the successful request I see:

Aug 3 10:02:36 www slapd[2864]: bdb_idl_fetch_key: [c5eaef7a]
Aug 3 10:02:36 www slapd[2864]: <= bdb_index_read: failed (-30990)
Aug 3 10:02:36 www slapd[2864]: <= bdb_inequality_candidates: id=3061, first=851, last=4937
Aug 3 10:02:36 www slapd[2864]: <= bdb_filter_candidates: id=3061 first=851 last=4937
Aug 3 10:02:36 www slapd[2864]: <= bdb_list_candidates: id=19 first=991 last=4918
Aug 3 10:02:36 www slapd[2864]: <= bdb_filter_candidates: id=19 first=991 last=4918
Aug 3 10:02:36 www slapd[2864]: => bdb_filter_candidates
Aug 3 10:02:36 www slapd[2864]: EQUALITY
Aug 3 10:02:36 www slapd[2864]: => bdb_equality_candidates (objectClass)
Aug 3 10:02:37 www slapd[2864]: => key_read
Aug 3 10:02:37 www slapd[2864]: bdb_idl_fetch_key: [1c3c98ec]
Aug 3 10:02:37 www slapd[2864]: <= bdb_index_read 4087 candidates
Aug 3 10:02:37 www slapd[2864]: <= bdb_equality_candidates: id=4087, first=851, last=4937
Aug 3 10:02:37 www slapd[2864]: <= bdb_filter_candidates: id=4087 first=851 last=4937
Aug 3 10:02:37 www slapd[2864]: => bdb_filter_candidates
Aug 3 10:02:37 www slapd[2864]: EQUALITY
Aug 3 10:02:37 www slapd[2864]: => bdb_equality_candidates (gosptype)
Aug 3 10:02:37 www slapd[2864]: => key_read
Aug 3 10:02:37 www slapd[2864]: bdb_idl_fetch_key: [8f9a8f82]
Aug 3 10:02:37 www slapd[2864]: <= bdb_index_read 3779 candidates
Aug 3 10:02:37 www slapd[2864]: <= bdb_equality_candidates: id=3779, first=851, last=4629
Aug 3 10:02:37 www slapd[2864]: <= bdb_filter_candidates: id=3779 first=851 last=4629
Aug 3 10:02:37 www slapd[2864]: <= bdb_list_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: <= bdb_filter_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: <= bdb_list_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: <= bdb_filter_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: <= bdb_list_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: <= bdb_filter_candidates: id=16 first=991 last=4029
Aug 3 10:02:37 www slapd[2864]: bdb_search_candidates: id=16 first=991 last=4029

...followed by a series of direct comparisons of a seemingly random subset of entries to the filter. Here are the gospqualifier values that make it to the direct comparison stage:

400603
401349
401419
401536
402025
410321
410527
410714
410835
411542
420249
420436
420519
421324 yes it matches!
421325 yes it matches!
430666 satan?

In short, I think there's something wrong with inequality search operations in OpenLDAP 2.3.4. Sorry for the lengthy post. Any insights or suggestions?

Jon Roberts
www.mentata.com