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

inequality searches cause slapd to freeze

FC3, OpenLDAP 2.2.23, BDB 4.2.52

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


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:


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