~stewart/drizzle/bug720552

in optimization for MIN() on indexed field, the result of Cursor::startIndexScan was not checked before calling other index functions on the Cursor. 

The optimizer has the ability to replace certain MIN() queries with a constant.

e.g.
CREATE TABLE t1 (a int, index(a));
.... insert data ...
SELECT MIN(a) FROM t1;

Will execute a lookup on the first record of the index and replace that part of the query tree with a constant.

In the code in sum.cc which executes this optimization, although the return code from startIndexScan was being saved, the variable was immediately overwritten by a subsequent call to (e.g.) index_first. This meant that if a StorageEngine did not save the error code and return it on subsequent index calls, we could (at best) crash.

At some point in the past, the InnoDB devs figured this out, and on error in getting the index, set things appropriately so that anywhere we subsequently get a row_search_for_mysql() call, we'll get back an error code again. I have not audited all index code paths to ensure this is the case everywhere. If one of the index code paths didn't call row_search_for_mysql() or do appropriate checks, we'd probably crash. The scenarios where this would be possible would possibly be around a ongoing transaction accessing a newly created/deleted table or a table protobuf message not matching the table in innodb.

MyISAM and ARCHIVE just sets a local variable and does nothing in doStartIndexScan that could possibly fail.

It looks as though this could cause a crash in PBXT and HailDB.

A way to test this is with storage_engine_api_tester injecting an error into the codepath.