Comment 2 for bug 1006164

The cause of the problem is
- a multi-table DELETE attempts to use an index_merge/intersect +"Using index" to read rows.
   = (for single-table DELETE, the problem doesnt show up, because index_merge/intersect is disabled)
- "Using index" means that index_merge will read each column value from its index, and try to assemble a record from them (the record is needed to check the WHERE clause).
- the table is used in DELETE, so table->no_keyread==TRUE. opt_range.cc has this [ancient] code:

int QUICK_RANGE_SELECT::init_ror_merged_scan(bool reuse_handler)
{
...
    if (!head->no_keyread)
    {
      doing_key_read= 1;
      head->mark_columns_used_by_index(index);
    }
....

I don't understand the reasoning behind it, but its result is that we will fail to call head->mark_columns_used_by_index(index). This didn't cause the problem up to version 5.2, because opt_range also used old "useless-stub" MRR, which had handler::read_multi_range_first(), which had a call to
table->mark_columns_used_by_index_no_reset(), which fixed things.
However, in 5.3's new MRR we have removed that (because it's generally not needed), and hence this bug.