• Kirill Smelkov's avatar
    Add test for splitX bug fix covering logic handling splits on edges · 2a93ae07
    Kirill Smelkov authored
    Commit 5c732b36 (Fix splitX bug.) in particular modified splitX to redo
    the search on current level when key hits exactly kx slot in splitted X.
    
    However this is not tested at all as with current tests nothing breaks with the
    following patch:
    
    	@@ -546,10 +546,11 @@ func (t *Tree) Set(k interface{} /*K*/, v interface{} /*V*/) {
    	                i, ok := t.find(q, k)
    	                if ok {
    	                        switch x := q.(type) {
    	                        case *x:
    	                                if x.c > 2*kx {
    	+                                       panic("splitX ; ok=T")
    	                                        x, i = t.splitX(p, x, pi, i)
    	                                }
    	                                pi = i + 1
    	                                p = x
    	                                q = x.x[i+1].ch
    
    The relookup handling is needed exactly for ok=true case bacause if key is in
    xk slot there are 2 cases:
    
    1) key < x.x[xk].k  : here splitX is ok to let search follow left split child
    2) key = x.x[xk].k  : here splitX needs to let search follow right split child (*)
    
    and splitX, when knowing key comes from xk entry, does not bother itself with
    deciding which way to go (1 or 2) and for this case just follows up to make the
    search relookup current level after split.
    
    We can make existing tests cover this logic by raising N in TestSetGet2.
    However for kx=32, kd=32 N has to be increased more than 100x which, on my
    computer, increases the time to run TestSetGet2 from 0.5s to more than 200s,
    and still with it it only covers case when X does not have a parent.
    
    So instead of increasing N to be very large and slow down testing, let's add
    explicit test for this particular case.
    
    (*) reminder:
    
    `i, ok := find(q, k)` finds i corresponding to entry in q with min(k' : k <= k')
    (entry at i=q.c is always handled as with k'=∞)
    
    NOTE the "or-equal" in comparision. However keys in data (d) and index (x) page
    entries are treated differently. When find finds an entry with exact match (ok=true):
    
    - for d: d[i] is used
    
    	https://github.com/cznic/b/blob/aaaa43c9/btree.go#L409
    	https://github.com/cznic/b/blob/aaaa43c9/btree.go#L558
    
    - for x: x[i+1] is used:
    
    	https://github.com/cznic/b/blob/aaaa43c9/btree.go#L406
    	https://github.com/cznic/b/blob/aaaa43c9/btree.go#L555
    
    in other words keys located at index page entries says: all keys in child are
    strictly less than this key.
    
    This is probably so organized to help splitting - so split can pick lowest data
    entry from right data page and use its key as key in parent index entry for
    left data sibling directly.
    2a93ae07
all_test.go 23.3 KB