Skip to content

Commit 5684818

Browse files
mayprasadahlerlend
authored andcommitted
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
1 parent eaae21c commit 5684818

File tree

3 files changed

+466
-2309
lines changed

3 files changed

+466
-2309
lines changed

0 commit comments

Comments
 (0)