Details
-
Bug
-
Status: Stalled (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.4(EOL)
-
None
Description
ALTER TABLE .. NOWAIT/WAIT is implemented by doing an implicit
SET STATEMENT lock_wait_timeout=#, innodb_lock_wait_timeout=# FOR ALTER ...
This is a unworkable solution because of the following problem:
- If there is any concurrent SELECT (especially from information schema) or DDL's that updates any of the following tables, there may be lock waits which will cause the tables to not be updated even if the ALTER TABLE was successful:
- table_stats
- index_stats
- column_stats
- general_log
- slow_log
At least for the persistent statistics tables the update will be silently ignored, which will result in totally wrong (for example in case of rename of columns or indexes) or stale statistics (in case of removing columns). For DBUG servers, there can be crashes because of lock errors that where not properly handled (as seen by Elena).
Instead of implementing this with SET STATEMENT, the timeout settings should be done inside ALTER TABLE and ONLY be around the execution of the ALTER. The lock timeouts should be restored before any logging calls or calls to delete table statistics.
In 10.6 the table statistics will be deleted after the ALTER TABLE has succeeded, instead of as in 10.4-10.5 when they are updated during initialization of the ALTER TABLE structures, which causes statistics to be deleted even if ALTER TABLE fails/rolls back.