EXPLAIN INSERT ... SELECT tried to use SELECT's execution path. This
caused a collection of problems:
- SELECT_DESCRIBE flag was not put into select_lex->options, which
means it was not in JOIN::select_options either (except for the first
member of the UNION).
- This caused UNION members to be executed. They would attempt to write
join output rows to the output.
- (Actual cause of the crash) second join sibling would call
result->send_eof() when finished execution. Then,
Explain_query::print_explain would attempt to write to query output
again, and cause an assertion due to non-empty query output.
[EXPLAIN] INSERT .. SELECT creates a select_insert object.
select_insert calls handler->start_bulk_insert() during
initialization.
For MyISAM/Aria this requires that a matching call to
handler->end_bulk_insert() call is made.
Regular INSERT .. SELECT accomplishes this by calling either
select_result->send_eof() or select_result->abort_result_set().
EXPLAIN INSERT ... SELECT didn't call either, which resulted in
improper de-initializaiton of handler object. Make it call
abort_result_set(), which invokes handler->end_bulk_insert().
- Don't save UNION's EXPLAIN data if optimization failed with
an error. We could end up saving incomplete plan, which will
cause a crash when we attempt to print it.
- Query plan footprint (in new terms, "EXPLAIN structure") should always keep
a copy of key_name. This is because the table might be a temporary table which
may be already freed by the time we use query plan footprint.
