Bug #14227431: CHARACTER SET MISMATCH WHEN ALTERING FOREIGN KEYS
CAN LEAD TO MISSING TABLES Overview -------- If the FOREIGN_KEY_CHECKS system variable is set to 0, it is possible to break a foreign key constraint by changing the type or character set of the foreign key column, or by dropping the foreign key index (without carrying out corresponding changes on another table in the relationship). If we subsequently set FOREIGN_KEY_CHECKS to 1 and execute ALTER TABLE involving the COPY algorithm on such a table, the following happens: 1) If ALTER TABLE does not contain a RENAME clause, the attempt to install the new version of the table instead of the old one will fail due to the fact that the inconsistency will be detected. An attempt to revert the partially executed alter table operation by restoring the old table definition will fail as well due to FOREIGN_KEY_CHECKS == 1. As a result, the table being altered will be lost. 2) If ALTER TABLE contains the RENAME clause, the inconsistency will not be detected (most probably due to other bugs). But if an attempt to install the new version of the table fails (for example, due to a failure when updating triggers associated with the table), reverting the partially executed alter table by restoring the old table definition will fail too. So the table being altered might be lost as well. Suggested fix ------------- The suggested fix is to temporarily unset the option bit representing FOREIGN_KEY_CHECKS when the old table definition is restored while reverting the partially executed operation.
Showing
Please register or sign in to comment