Fix for bug#22369: Alter table rename combined
with other alterations causes lost tables Using RENAME clause combined with other clauses of ALTER TABLE led to data loss (the data was there but not accessible). This could happen if the changes do not change the table much. Adding and droppping of fields and indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation, if the actual column didn't change (changing from int to int, which is a noop) Depending on the storage engine (SE) the behavior is different: 1)MyISAM/MEMORY - the ALTER TABLE statement completes without any error but next SELECT against the new table fails. 2)InnoDB (and every other transactional table) - The ALTER TABLE statement fails. There are the the following files in the db dir - `new_table_name.frm` and a temporary table's frm. If the SE is file based, then the data and index files will be present but with the old names. What happens is that for InnoDB the table is not renamed in the internal DDIC. Fixed by adding additional call to mysql_rename_table() method, which should not include FRM file rename, because it has been already done during file names juggling.
Showing
Please register or sign in to comment