oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

It turns out that ha_oqgraph::records_in_range() tests the keys, and although
there is a comment about latch not being null, doesnt specifically test for
the latch key not being null.  For some reason this code exdecuted differently
between debug and release but specifically checking for null seems to fix the
problem...


On 09/08/13 22:30, Andrew McDonnell wrote:
> I thought I was nearly done for today, then this bit me:
> 
> Consider the following queries:
> 
> (a) SELECT count(*) FROM graph;
> (b) SELECT * FROM graph where latch is NULL;
> (c) SELECT * FROM graph where latch='';
> (d) SELECT * FROM graph where latch='0';
> 
> 
> In my debug build, (a) and (b) reutrn the same - the set of pairs,
> and (c) and (d) the same - the set of vertices in linkid aka no_search
> 
> My understanding of the requirements is that the above is the correct
> behaviour, is this true?
> 
> BUT
> 
> In the default cmake build, (b) returns the same as (c) and (d)
> 
> Thus, case (b) `is NULL` has a problem...
> 
> Some initial observations after I eventually had to resort to gdb indicate
> that the debug build uses the random scan (edges cursor) and the normal build
> ends up doing a no_search for is NULL.
> 
> This is crazy!
> 
> Only thing I can think of is, somewhere, a variable is not initialised and
> gets set differently in the debug build?
> 
> The code passes through index_read_idx() for the default build for `is NULL` ,
> producing the incorrect behaviour, and doesnt for the debug build.
> 
> This is frustrating!  This causes the basic.test to fail...
> 
> The entry points are external to our code, indicating the query optimiser is
> making the choice to pass `is NULL` as a where clause to one path or the other
> (my best estimate given my limited knowlegde of the inner workings of mysql)
> 
> My debug build appends -DCMAKE_BUILD_TYPE=Debug"
> 
> --ANdrew
>