Description:
Using a snapshot (vision) captured before the table structure modification, a parallel COUNT(*) query on the modified table structure executes without errors.
We think the problematic code lies in the logic of ha_innopart::records handling parallel COUNT(*) operations.
Because ha_innobase::records handles the case where !index->is_usable, while ha_innopart::records appears to overlook this scenario when processing parallel COUNT(*) operations.
How to repeat:
The following COUNT(*) queries are all parallel reads：
session 1:
begin;
select count(*) from t1;
session 2:
alter table t2 add column c int;
session 1:
select count(*) from t2;
If t2 is a non-partitioned table, it throws an error: Table definition has changed, please retry transaction.
If t2 is a partitioned table, the query can still be executed, which is considered unexpected behavior.
For the final query in Session 1, we also tested non-parallel read operations, such as SELECT * FROM t2;
Results as follows:
If t2 is a non-partitioned table, it throws an error: Table definition has changed, please retry transaction.
If t2 is a partitioned table, it throws an error: Table definition has changed, please retry transaction.
In a word, among the four scenarios, only the partitioned table executing a parallel COUNT(*) did not report errors, which seems to be a bug.
Suggested fix:
In the logic of ha_innopart::records handling parallel COUNT(*) operations，add code to handle the HA_ERR_TABLE_DEF_CHANGED scenario.
