[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: substring searches very broken HELP HELP URGENT :-( (ITS#402)
On Thu, Dec 16, 1999 at 04:20:05PM -0800, Kurt D. Zeilenga wrote:
> >I recreated the database with a scratch openldap-1.2.8 with ldif2ldbm from
> >the ldif created by the 1.2.7 ldbmcat, and the problem is still there.
>
> You might try using 'ldbmcat -n' and then use ldapadd.
Ok, I'm nearly there. An excerpt from the trace log (which has been expanded
a bit by additional logging). id 301 is the one we are looking for.
=> index_read( "maildrop" "*" "592" )
=> ldbm_cache_open( "/var/ldap2//maildrop.gdbm", 2, 600 )
<= ldbm_cache_open (cache 3)
<= index_read 166 candidates
ID_BLOCK_NIDS(a): 3
ID_BLOCK_NIDS(b): 166
[0]301 == [0]301
[102]31938 == [1]31876
[104]32765 == [2]32249
idl_intersection: 1 left
=> index_read( "maildrop" "*" "92-" )
=> ldbm_cache_open( "/var/ldap2//maildrop.gdbm", 2, 600 )
<= ldbm_cache_open (cache 3)
<= index_read 364 candidates
ID_BLOCK_NIDS(a): 1
ID_BLOCK_NIDS(b): 364
[4]301 == [0]301
idl_intersection: 1 left
=> 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) 2 blocks
=[0]5
=[1]14
=[2]48
=[3]57
=[4]71
=[5]76
=[6]77
(...)
=[2039]48606
=[2040]48625
=[2041]48626
=[2042]48628
=[2043]48633
=[2044]48644
=[2045]48664
=[2046]13
=[2047]16
=[2048]62
=[2049]85
=[2050]233
=[2051]249
=[2052]301
=[2053]360
(...)
=[3654]56210
=[3655]56223
=[3656]56234
=[3657]56235
=[3658]56260
<= index_read 3659 candidates
ID_BLOCK_NIDS(a): 1
ID_BLOCK_NIDS(b): 3659
[19]302 == [0]301
ni==0
<= substring_comp_candidates 0
This is wrong. Data has been inserted in the wrong block and because data is
now no longer in the right order, idl_intersection (which has been
optimized) fails.
I'm still investigating this further..
Regards,
bert hubert.
--
+---------------+ | http://www.rent-a-nerd.nl
| nerd for hire | |
+---------------+ | - U N I X -
| | Inspice et cautus eris - D11T'95