-
Darshan M N authored
ROW0ROW.CC:299 Problem: ======== The column ord_part is being reset in innobase_rollback_sec_index(). When we are doing the reset, we check if any column is part of any existing index and if not, we reset the respective column's ord_part. During this check, in check_col_exists_in_indexes(), we skip the check for an index whose to_be dropped value is set. Now, consider the case where we do "ALTER TABLE DROP INDEX idx(col1), ADD INDEX (col2)" and the alter fails for some reason. In this case, initially col1's to_be_dropped value would be set and this value is reset only after innobase_rollback_sec_index(), which means, in check_col_exists_in_indexes(), we skip the check for this index and as a result col1's ord_part is reset and this results in the assert. Fix: ==== Moved the reset of ord_part code from innobase_rollback_sec_index() to the place after we reset the to_be_dropped value, during rollback. RB: 12618 Reviewed-by:
Jimmy Yang <Jimmy.Yang@oracle.com>
Darshan M N authoredROW0ROW.CC:299 Problem: ======== The column ord_part is being reset in innobase_rollback_sec_index(). When we are doing the reset, we check if any column is part of any existing index and if not, we reset the respective column's ord_part. During this check, in check_col_exists_in_indexes(), we skip the check for an index whose to_be dropped value is set. Now, consider the case where we do "ALTER TABLE DROP INDEX idx(col1), ADD INDEX (col2)" and the alter fails for some reason. In this case, initially col1's to_be_dropped value would be set and this value is reset only after innobase_rollback_sec_index(), which means, in check_col_exists_in_indexes(), we skip the check for this index and as a result col1's ord_part is reset and this results in the assert. Fix: ==== Moved the reset of ord_part code from innobase_rollback_sec_index() to the place after we reset the to_be_dropped value, during rollback. RB: 12618 Reviewed-by:
Jimmy Yang <Jimmy.Yang@oracle.com>
Loading