Sergei Golubchik added a comment - 2014-06-23 20:25 about the external_lock() approach: it's up to the engine to ensure that the table definition doesn't change if the table is external_lock'ed. If the table definition still changes, we issue an error. Our the use case is — a table is taken from the table cache. Nobody has external_lock'ed it yet. So, when we do external_lock() and get HA_ERR_TABLE_DEF_CHANGED in return, we can expect that probably nobody else is using this table at the moment. We have some kind of the metadata lock on this table. Ask MDL subsystem to upgrade it to the exclusive lock or fail immediately if it's impossible (there is a conflicting lock on the table). This breaks the strict locking order, but because it never waits (instead it fails at once), this can never cause deadlocks. in most cases it should not fail — if it does, it means that somebody is using the table, so this somebody's external_lock should have prevented the table definition from being changed, and we should not have got HA_ERR_TABLE_DEF_CHANGED in the first place if it still fails — return an error to the user, as before if we got our exclusive metadata lock, we can close and reopen the table. same logic should be used inside open_table(), instead of backoff-and-retry.