inequality searches cause slapd to freeze

[Jon Roberts <jon@jonanddeb.net>]

FC3, OpenLDAP 2.2.23, BDB 4.2.52

In a previous post, I had discussed problems using filters with => <= 
operators.

http://www.openldap.org/lists/openldap-software/200412/msg00166.html

In the response, Howard Chu indicated potential support for inequality 
indexing on integer types. I later changed my attributes to integer 
syntax, and upgraded to OpenLDAP 2.2.23. Recoding my clients to use 
these filters again, I got pretty speedy performance (where loglevel was 
0), and so I made a mistaken assumption that the function had in fact 
been implemented. The filters now look something like this:

(&(&(gospqualifier>=400624)(gospqualifier<=400634))(objectClass=gosp)(gosptype=verse))

Unfortunately, I have discovered that after running something like a 
dozen of these searches without issue, slapd hangs permanently on the 
next such request. I cranked up the logs (loglevel -1) to see what was 
happening, and soon discovered that each such search leads to a an 
iterative comparison of each and every verse entry (3779) to the filter 
to determine matches. The logs, you might guess, are voluminous. Since 
the performance sans logs is okay, that really doesn't matter to me 
right now so much as the slapd crash, which the logs don't explain other 
than to stop at a point immediately before the inequality search 
commences (as compared to what I see for a succesful inequality search).

I can recreate this same condition on a separate box running RH9, 
OpenLDAP 2.2.23, BDB 4.2.52, so it seems systematic. Each inequality 
search I perform is preceded by a request for the entry representing the 
passage itself, but otherwise the directory is unoccupied.

Any ideas what might be happening here?

Jon Roberts
www.mentata.com