MDEV-17494 Refuse ALGORITHM=INSTANT when the row size is too large
With the MDEV-15562 instant DROP COLUMN, clustered index records will contain traces of dropped columns, as follows: In ROW_FORMAT=REDUNDANT, dropped columns will be stored as 0 bytes, but they will consume 1 or 2 bytes per column in the record header. In ROW_FORMAT=COMPACT or ROW_FORMAT=DYNAMIC, dropped columns will be stored as NULL if allowed. This will consume 1 bit per nullable column. In ROW_FORMAT=COMPACT or ROW_FORMAT=DYNAMIC, dropped NOT NULL columns will be stored as 0 bytes if allowed. This will consume 1 byte per NOT NULL variable-length column. Fixed-length columns will be stored using the fixed number of bytes. The metadata record will be 20 bytes larger than user records, because it will contain a metadata BLOB pointer. We must refuse ALGORITHM=INSTANT (and require a table rebuild) if the metadata record would grow too big to fit in the index page. If SQL_MODE includes STRICT_TRANS_TABLES or STRICT_ALL_TABLES, we should refuse ALGORITHM=INSTANT if the maximum length of user records would exceed the maximum size of an index page, similar to what row_create_index_for_mysql() does during CREATE TABLE. This limit would kick in when the default values for any instantly added columns in the metadata record are NULL or short, but the allowed maximum values are long. instant_alter_column_possible(): Add the parameter "bool strict" to enable checks for the user record size, and always check the metadata record size.
Showing
Please register or sign in to comment