BUG#693747: Assertion multi_range_read.cc:908: int DsMrr_impl::dsmrr_init

- Make DsMrr_impl::dsmrr_init() handle the case of 
   1. 1st MRR scan using DS-MRR strategy (i.e. doing key sorting and rowid sorting)
   2. 2nd MRR scan getting a buffer that's too small to fit one key element 
      and one rowid element, and so falling back to default MRR implementation
  In this case, dsmrr_init() is invoked with {primary_handler, secondary_handler}
  initialized for DS-MRR scan and have to reset them to be initialized for the
  default MRR scan.
(attempt 2, with simplified testcase)

1 files changed, 20 insertions, 1 deletions

diff --git a/sql/multi_range_read.cc b/sql/multi_range_read.cc
index 0c8b60b72ed..01a6dbb9b8f 100644
--- a/sql/multi_range_read.cc
+++ b/sql/multi_range_read.cc
@@ -907,7 +907,26 @@ error:
   DBUG_RETURN(res);
 
 use_default_impl:
-  DBUG_ASSERT(primary_file->inited == handler::INDEX);
+  if (primary_file->inited != handler::INDEX)
+  {
+    /* We can get here when 
+       - we've previously successfully done a DS-MRR scan (and so have 
+         secondary_file!= NULL, secondary_file->inited= INDEX, 
+         primary_file->inited=RND)
+       - for this invocation, we haven't got enough buffer space, and so we
+         have to use the default MRR implementation.
+
+      note: primary_file->ha_index_end() will call dsmrr_close() which will
+      close/destroy the secondary_file, this is intentional. 
+      (Yes this is slow, but one can't expect performance with join buffer 
+       so small that it can accomodate one rowid and one index tuple)
+    */
+    if ((res= primary_file->ha_rnd_end()) || 
+        (res= primary_file->ha_index_init(keyno, test(mode & HA_MRR_SORTED))))
+    {
+      DBUG_RETURN(res);
+    }
+  }
   /* Call correct init function and assign to top level object */
   Mrr_simple_index_reader *s= &reader_factory.simple_index_reader;
   res= s->init(primary_file, seq_funcs, seq_init_param, n_ranges, mode, NULL,