You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#37061960 : InnoDB redo recovery failure/corruption due to INSTANT ddl.+ innodb col limits
Symptom :
- Maximum number of user columns in a table supported in InnoDB is 1017.
- Metadata of Columns, dropped with ALGORITHM=INSTANT, is kept and these
columns are also counted in that limit of 1017.
- With DROP and ADD colimn combination, it was possible to have number of
columns cross maximum allowed column limit.
- And there were assertion failures during recovery during replaying the
INSERT opertation on this table.
- This is a boundary case.
Root cause:
- We try to make sure to limit the total number of columns within limit.
- But while checking maximum number of columns REC_MAX_N_FIELDS is used.
REC_MAX_N_FIELDS value is 1023 (1017 + 6).
- 6 is for twice the number of system columns (DATA_N_SYS_COLS).
- These system cols are DB_ROW_ID, DB_TRX_ID, DB_ROLL_PTR.
- why twice? Code comments says the following :
"
We need "* 2" because mlog_parse_index() creates a dummy table object
possibly, with some of the system columns in it, and then adds the 3
system columns (again) using dict_table_add_system_columns(). The problem
is that mlog_parse_index() cannot recognize the system columns by
just having n_fields, n_uniq and the lengths of the columns.
"
Fix :
In check_if_supported_inplace_alter, correct the check for maximum possible
columns to keep it within 1017.
Change-Id: I9d6c3183373b8acb269fe6ac6fb2e2bb2a0495ed
0 commit comments