Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
Description
Currently, mysql_inplace_alter_table() in sql/sql_table.cc does the following:
// Upgrade to EXCLUSIVE before commit. |
if (wait_while_table_is_used(thd, table, HA_EXTRA_PREPARE_FOR_RENAME)) |
goto rollback; |
During this time, the ALTER TABLE thread is not doing anything useful. If this is a table-rebuilding ALTER TABLE operation (something that cannot be done as ALGORITHM=INSTANT (MDEV-13134) until parts of MDEV-11424 are finished, or if rebuild was requested by specifying the FORCE keyword), then it would make sense to let InnoDB invoke row_log_table_apply() after a request to upgrade the lock has been submitted.
I would like to consider adding a variant of the ha_innobase::inplace_alter_table() call that would let InnoDB invoke the next batch of row_log_table_apply(). Once this call returns, the caller would check if the ALTER TABLE operation was killed or the MDL upgrade timed out, or the MDL was granted. As long as the lock wait should continue, the storage engine would be called again to do useful work during the wait.
Attachments
Issue Links
- relates to
-
MDEV-16329 Engine-independent online ALTER TABLE
- Closed
-
MDEV-11424 Instant ALTER TABLE of failure-free record format changes
- Closed
-
MDEV-13134 Introduce ALTER TABLE attributes ALGORITHM=NOCOPY and ALGORITHM=INSTANT
- Closed
-
MDEV-34988 InnoDB locks dict_sys.latch for a long time during ALTER TABLE
- Open