Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
Description
We have several points of synchronization during ALTER TABLE COPY.
If it gets blocked by some concurrent transaction, the progress reported
zeros for both the initial lock and the final lock upgrade with the message
"Waiting for table metadata lock".
So it was unclear what stage does ALTER TABLE is hanging at: in the
beginning, or in the end.
here's an example test:
--source include/have_innodb.inc
|
|
|
set default_storage_engine= innodb;
|
|
|
--connect (con2, localhost, root,,)
|
|
|
create or replace table t1 (a int);
|
show create table t1;
|
insert t1 values (5);
|
|
|
--connection con2
|
begin;
|
select * from t1;
|
--connection default
|
--let $con= `select connection_id()`
|
send alter table t1 add b int NULL, algorithm= copy, lock= none;
|
|
|
--connection con2
|
eval set @con= $con;
|
|
|
--sleep 1
|
query_vertical
|
select * from information_schema.processlist where id = @con;
|
|
|
rollback;
|
The sample actual output for the last select is:
select * from information_schema.processlist where id = @con;
|
ID 4
|
USER root
|
HOST localhost
|
DB test
|
COMMAND Query
|
TIME 1
|
STATE Waiting for table metadata lock
|
INFO alter table t1 add b int NULL, algorithm= copy, lock= none
|
TIME_MS 1005.836
|
STAGE 0
|
MAX_STAGE 0
|
PROGRESS 0.000
|
MEMORY_USED 78528
|
MAX_MEMORY_USED 259632
|
EXAMINED_ROWS 0
|
QUERY_ID 32
|
INFO_BINARY alter table t1 add b int NULL, algorithm= copy, lock= none
|
TID 103286
|
would be nice to have clear stages and progress though