doStartIndexScan return code ignored in optimizer::sum_query() for MIN() optimization

Bug #720552 reported by Stewart Smith on 2011-02-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Stewart Smith
Stewart Smith

Bug Description

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

CREATE TABLE t1 (a int, index(a));
.... insert data ...

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 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.

Related branches

Stewart Smith (stewart) on 2011-02-17
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers