From: Rich Prohaska Date: August 31 2012 5:17pm Subject: Schema inconsistency after inplace alter table in MySQL 5.6.6-m9 List-Archive: http://lists.mysql.com/internals/38579 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Hello, TokuDB supports inplace alter table operations including inplace column addition. While implementing this feature on MySQL 5.6 we encountered a schema inconsistency problem that occurs if mysqld crashes in the right place during an inplace alter table operation (described below). We uses the FRM discovery mechanism to resync MySQL's view of the schema with the TokuDB view of the schema. We also implemented FRM discovery in the partition storage engine. If MySQL made the FRM rename operation transactional, then there would be no need to synchronize the schema with the discovery mechanism. Here are some details. Suppose that one has a simple table: create table t (a int primary key); and one adds a new column to the table: alter table t add column b int; If mysqld crashes after the inplace alter operation is committed and the table is closed but before the new FRM file is renamed, then when mysqld comes up after the crash, the table schema described by the FRM (the old FRM) is inconsistent with the engine's schema since the new schema was committed. TokuDB uses FRM discovery to resync the FRM schema with the engine's view of the schema. Now, suppose that one has a partitioned table: create table t (a int primary key) partition by... and one adds a new column to the table: alter table t add column b int; If mysqld crashes during the alter table operation, the table schema described by the old FRM is inconsistent with the engines' schema. If the partition storage engine supported FRM discovery, then the inconsistency could be resolved. Unfortunately, it does not. Just for fun, we implemented FRM discovery in the partition storage engine. It retrieves the FRM from the engine (if possible) and returns it. The problem with inplace alter table operations isthat the rename of the FRM schema is not transactional. Are there any plans to address this?