-
Dmitry Lenev authored
Enable RENAME TABLES usage under LOCK TABLES. The following restrictions apply: *) Source table must be locked for write or must be product of previous steps in the same multi-table RENAME TABLES statement. *) In cases when RENAME TABLES introduces new parent table for previously orphan foreign key, the child table of this foreign key is locked for write to preserve foreign key invariants for LOCK TABLES. After successful RENAME TABLES the renamed tables stay available as open and locked table under their new names. Failed RENAME TABLES which manages to fully revert its changes should keep tables available as open and locked under their old names. The above was implemented by: 1) Removing check prohibiting RENAME TABLES in LOCK TABLES mode. 2) Adding checks for the above restrictions in case when RENAME TABLES is attempted in LOCK TABLES mode. 3) Adjusting existing lock_table_names() call in RENAME TABLES implementation to also handle acquisition/upgrade of metadata locks on tables being renamed in LOCK TABLES case. 4) Adding code to close tables being renamed in LOCK TABLES mode in a way that allows their reopen later. 4) Adding code which reopens tables renamed after RENAME TABLES commit or rollback. 5) Adding code which keeps SNRW metadata locks on new table names after successful RENAME TABLES end and releases locks on old table names. Also IX locks on new schema names are kept. To support this lock_table_names() call was extended to return set of schema locks it acquires in optional out parameter. 6) Code handling reversal of non-atomic RENAME TABLES in case of its failure was changed to not ignore errors. This allows us to distinguish case when RENAME TABLES was fully reverted from partial revert case. In the former case we can simply release all metadata locks acquired by failed RENAME TABLES. The latter case is handled by removing tables renamed from the set of open and locked tables but requires keeping metadata locks on new tables for safety. 7) ALTER TABLE ... RENAME code was adjusted to keep IX metadata locks on new schema after its end under LOCK TABLES. Alter_table_ctx class was extended to make it easier. Test coverage for new code was added to main.rename and main.rename_debug tests. main.merge test was adjusted to take new behavior of RENAME TABLES into account. Adjusted main.alter_table-big test to provide proper coverage for ALTER TABLE RENAME change. Added new subtest to main.view test to improve code coverage for RENAME TABLES.
Dmitry Lenev authoredEnable RENAME TABLES usage under LOCK TABLES. The following restrictions apply: *) Source table must be locked for write or must be product of previous steps in the same multi-table RENAME TABLES statement. *) In cases when RENAME TABLES introduces new parent table for previously orphan foreign key, the child table of this foreign key is locked for write to preserve foreign key invariants for LOCK TABLES. After successful RENAME TABLES the renamed tables stay available as open and locked table under their new names. Failed RENAME TABLES which manages to fully revert its changes should keep tables available as open and locked under their old names. The above was implemented by: 1) Removing check prohibiting RENAME TABLES in LOCK TABLES mode. 2) Adding checks for the above restrictions in case when RENAME TABLES is attempted in LOCK TABLES mode. 3) Adjusting existing lock_table_names() call in RENAME TABLES implementation to also handle acquisition/upgrade of metadata locks on tables being renamed in LOCK TABLES case. 4) Adding code to close tables being renamed in LOCK TABLES mode in a way that allows their reopen later. 4) Adding code which reopens tables renamed after RENAME TABLES commit or rollback. 5) Adding code which keeps SNRW metadata locks on new table names after successful RENAME TABLES end and releases locks on old table names. Also IX locks on new schema names are kept. To support this lock_table_names() call was extended to return set of schema locks it acquires in optional out parameter. 6) Code handling reversal of non-atomic RENAME TABLES in case of its failure was changed to not ignore errors. This allows us to distinguish case when RENAME TABLES was fully reverted from partial revert case. In the former case we can simply release all metadata locks acquired by failed RENAME TABLES. The latter case is handled by removing tables renamed from the set of open and locked tables but requires keeping metadata locks on new tables for safety. 7) ALTER TABLE ... RENAME code was adjusted to keep IX metadata locks on new schema after its end under LOCK TABLES. Alter_table_ctx class was extended to make it easier. Test coverage for new code was added to main.rename and main.rename_debug tests. main.merge test was adjusted to take new behavior of RENAME TABLES into account. Adjusted main.alter_table-big test to provide proper coverage for ALTER TABLE RENAME change. Added new subtest to main.view test to improve code coverage for RENAME TABLES.
Loading