Description:
Current MRR implementation of NDB produces wrong results when
read_multi_range_first() function has sorted=TRUE.
I was not able to find a sequence of SQL queries that would cause the wrong
result to be produced, but I'm filing this bug anyway, because
* we're very likely to hit this in 5.2 with batched key access.
* The current code doesn't behave according to our concept of how it
should, and we're going write more code according to that concept of ours.
If the displayed behavior is not a bug, then we (optimizer ppl) need
explanation why.
Get 5.2 tree
Apply the following patch:
===== ha_ndbcluster.cc 1.283 vs edited =====
*** /tmp/bk_ha_ndbcluster.cc-1.283_3elAez 2006-03-08 17:29:50 +03:00
--- edited/ha_ndbcluster.cc 2006-03-21 22:34:46 +03:00
***************
*** 7025,7030 ****
--- 7025,7031 ----
HANDLER_BUFFER *buffer)
{
DBUG_ENTER("ha_ndbcluster::read_multi_range_first");
+ sorted= TRUE;
m_write_op= FALSE;
int res;
===patch ends===
The patch should make MRR/NDB return table records in order, provided that
the input ranges are ordered.
Compile with ./BUILD/compile-pentium-debug-max
Run the test:
./mysql-test-run t/ndb_index_ordered.test
Observe this failure:
*** r/ndb_index_ordered.result Tue Mar 21 14:10:16 2006
--- r/ndb_index_ordered.reject Tue Mar 21 23:48:33 2006
***************
*** 239,246 ****
insert into t1 values(1,1,1),(2,NULL,2),(3,NULL,NULL),(4,4,NULL);
select * from t1 use index (bc) where b IS NULL order by a;
a b c
! 2 NULL 2
! 3 NULL NULL
select * from t1 use index (bc)order by a;
a b c
1 1 1
--- 239,245 ----
insert into t1 values(1,1,1),(2,NULL,2),(3,NULL,NULL),(4,4,NULL);
select * from t1 use index (bc) where b IS NULL order by a;
a b c
! 3 NULL 2779096485
select * from t1 use index (bc)order by a;
a b c
1 1 1
***************
<end of difference cut>
The above result difference shows that MRR/NDB implementation would return
random data (2779096485 == 0xa5a5a5a5 => uninitialized memory read) when
one tries to get an ordered output for a single "b=NULL" range (a valid
request in my understanding).
The tests that fail in similar way (wrong query results, not just records in different order) are: ndb_index_ordered.test, ndb_read_multi_range.test, ndb_index_unique.test.
How to repeat:
See above
Suggested fix:
Fix the MRR/NDB so when one
* applies the provided sorted=TRUE patch
* runs the test suite
one gets only test failures that show records returned in different order.
Description: Current MRR implementation of NDB produces wrong results when read_multi_range_first() function has sorted=TRUE. I was not able to find a sequence of SQL queries that would cause the wrong result to be produced, but I'm filing this bug anyway, because * we're very likely to hit this in 5.2 with batched key access. * The current code doesn't behave according to our concept of how it should, and we're going write more code according to that concept of ours. If the displayed behavior is not a bug, then we (optimizer ppl) need explanation why. Get 5.2 tree Apply the following patch: ===== ha_ndbcluster.cc 1.283 vs edited ===== *** /tmp/bk_ha_ndbcluster.cc-1.283_3elAez 2006-03-08 17:29:50 +03:00 --- edited/ha_ndbcluster.cc 2006-03-21 22:34:46 +03:00 *************** *** 7025,7030 **** --- 7025,7031 ---- HANDLER_BUFFER *buffer) { DBUG_ENTER("ha_ndbcluster::read_multi_range_first"); + sorted= TRUE; m_write_op= FALSE; int res; ===patch ends=== The patch should make MRR/NDB return table records in order, provided that the input ranges are ordered. Compile with ./BUILD/compile-pentium-debug-max Run the test: ./mysql-test-run t/ndb_index_ordered.test Observe this failure: *** r/ndb_index_ordered.result Tue Mar 21 14:10:16 2006 --- r/ndb_index_ordered.reject Tue Mar 21 23:48:33 2006 *************** *** 239,246 **** insert into t1 values(1,1,1),(2,NULL,2),(3,NULL,NULL),(4,4,NULL); select * from t1 use index (bc) where b IS NULL order by a; a b c ! 2 NULL 2 ! 3 NULL NULL select * from t1 use index (bc)order by a; a b c 1 1 1 --- 239,245 ---- insert into t1 values(1,1,1),(2,NULL,2),(3,NULL,NULL),(4,4,NULL); select * from t1 use index (bc) where b IS NULL order by a; a b c ! 3 NULL 2779096485 select * from t1 use index (bc)order by a; a b c 1 1 1 *************** <end of difference cut> The above result difference shows that MRR/NDB implementation would return random data (2779096485 == 0xa5a5a5a5 => uninitialized memory read) when one tries to get an ordered output for a single "b=NULL" range (a valid request in my understanding). The tests that fail in similar way (wrong query results, not just records in different order) are: ndb_index_ordered.test, ndb_read_multi_range.test, ndb_index_unique.test. How to repeat: See above Suggested fix: Fix the MRR/NDB so when one * applies the provided sorted=TRUE patch * runs the test suite one gets only test failures that show records returned in different order.