Comment 4 for bug 671340

Figured out the problem. The problem shows up when
- DS-MRR implementation uses both ordered key reading and rndpos()-based full record retrieval,
- the table is an innodb table with user-visible primary key. This is needed so that handler->position() call gets the rowid value from the last record we've read.

When the above is satisfied, we can have the following scenario:
- Mrr_ordered_index_reader fills the buffer, sorts it, starts to return rows.
- At some point where Mrr_ordered_index_reader is in the middle of scanning the list of ranges with identical key, the rowid buffer gets full
- Mrr_ordered_index_reader's scan is interrupted, Mrr_ordered_rndpos_reader starts making rnd_pos() calls and returning records. This process causes table->record[0] to be rewritten.
- Mrr_ordered_rndpos_reader exhausts the supply of rowids and turns to Mrr_ordered_index_reader to get more.
- Mrr_ordered_index_reader, assuming that table->record[0] still has the index record it was scanning, returns the next range_id.

=> Mrr_ordered_rndpos_reader gets a range_id with rowid that does not match the range_id.