MDEV-10087 mysqld_update()/mysql_delete() continues execution even after...
MDEV-10087 mysqld_update()/mysql_delete() continues execution even after subquery with JOIN gets error from storage engine The issue is that record_should_be_deleted() returns true in mysql_delete() even if sub-select with join gets error from storage engine when DELETE FROM ... WHERE ... IN (SELECT ...) statement is executed. The same is true for mysql_update() where select->skip_record() returns true even if sub-select with join gets error from storage engine. In the test case if sub-select is chosen as deadlock victim the whole transaction is rolled back during sub-select execution, but mysql_delete()/mysql_update() continues transaction execution and invokes table->delete_row() as record_should_be_deleted() wrongly returns true in mysql_delete() and table->update_row() as select->skip_record(thd) wrongly returns 1 for mysql_update(). record_should_be_deleted() wrogly returns true because thd->is_error() returns false SQL_SELECT::skip_record() invoked from record_should_be_deleted(). It's supposed that THD error should be set in rr_handle_error() called from rr_sequential() during sub-select JOIN::exec_inner() execution. But rr_handle_error() does not set THD error because READ_RECORD::print_error is not set in JOIN_TAB::read_record. READ_RECORD::print_error should be initialized in init_read_record()/init_read_record_idx(). But make_join_readinfo() does not invoke init_read_record()/init_read_record_idx() for JOIN_TAB::read_record. The fix is to set JOIN_TAB::read_record.print_error in make_join_readinfo(), i.e. in the same place where JOIN_TAB::read_record.table is set. Reviewed by Sergey Petrunya.
Showing
Please register or sign in to comment