Re: substring searches very broken HELP HELP URGENT :-( (ITS#402)

[ahu@casema.net]

On Thu, Dec 16, 1999 at 05:07:53PM +0000, kurt@boolean.net wrote:

> >	- run ldif2index on the copy and feed it the ldif created by
> >          ldbm2ldif (with another slapd.conf, so it generates the index
> 
> I suggest you run ldif2ldbm to rebuild the entire database.

That would be best. Until recently this wasn't an option until we discovered
that regenerating on Solaris /tmp is magnitudes faster than doing it on a
SCSI disk. Regenerating would've cost hours and hours.. (about 15, we
calculated).

> >to be sure if this would help us. I read here that 1.2.8 was worse in this
> >respect.
> 
> I believe the enabling of DN substring indexing in 1.2.7 caused
> some problems, it's disabled by default in 1.2.8.

Ok, I'm now running an extra copy of slapd on another port, on another
dataset, and we've been doing tracing. The initial results indicate that
there is a problem with superblocks:

=> index_read( "maildrop" "*" "592" )
=> ldbm_cache_open( "/var/ldap2/maildrop.gdbm", 2, 600 )
<= ldbm_cache_open (cache 3)
<= index_read 166 candidates
=> index_read( "maildrop" "*" "92-" )
=> ldbm_cache_open( "/var/ldap2/maildrop.gdbm", 2, 600 )
<= ldbm_cache_open (cache 3)
<= index_read 364 candidates
=> index_read( "maildrop" "*" "2-1" )
=> ldbm_cache_open( "/var/ldap2/maildrop.gdbm", 2, 600 )
<= ldbm_cache_open (cache 3)
<= idl_fetch 3659 ids (3659 max)
<= index_read 3659 candidates
<= substring_comp_candidates 0
idl_free: called with NULL pointer
<= filter_candidates 0
<= list_candidates 0
<= filter_candidates 0
send_ldap_result 0::
ber_flush: 14 bytes to sd 5
         0 0c 02 01 02  e 07 0a 01 00 04 00 04 00
listening for connections on 3, activity on: 5r
before select active_threads 0

Now, the amount of entries returned by idl_fetch is correct, on a 'working'
copy of the database, a search in *2-1* does indeed return 3659 entries,
including the one we were searching for here.

However, when idl_intersection is called, it finds zero remaining objects.
Though this may be caused by errors earlier on, I find it suspicious that
the error occurs just after searching a superblock.

I'll continue debugging 'till I've found the problem, your input would be
appreciated. Any patches resulting from this will obviously be posted.

Regards,

bert.

-- 
    +---------------+  |              http://www.rent-a-nerd.nl
    | nerd for hire |  |                  
    +---------------+  |                     - U N I X -
            |          |          Inspice et cautus eris - D11T'95