Problem found during RQG testing.

The maximum runtime (300s) of the RQG worker threads gets exceeded even though

the worker threads would exit in case this limit is already exceeded and the next query would have to be generated. This lets assume that the worker threads are since some long

timespan within the execution of a statement which has not finished yet.

The processlist shows the following

Id      User    Host    db      Command Time    State   Info    Progress

1       system user             NULL    Daemon  NULL    InnoDB purge worker     NULL    0.000

2       system user             NULL    Daemon  NULL    InnoDB purge coordinator        NULL    0.000

3       system user             NULL    Daemon  NULL    InnoDB purge worker     NULL    0.000

4       system user             NULL    Daemon  NULL    InnoDB purge worker     NULL    0.000

5       system user             NULL    Daemon  NULL    InnoDB shutdown handler NULL    0.000

8       root    localhost:56266 mysql   Sleep   671             NULL    0.000

16      root    localhost:56332 test    Query   659     preparing for alter table       ALTER TABLE t_09 DROP INDEX `Marvão_ftidx1`, ADD FULLTEXT INDEX `MarVão_ftidx1` ( col_text ), LOCK    0.000

17      root    localhost:56334 test    Query   655     setup   ALTER TABLE t_06 ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK = SHARED /* E_R Thread2 QNO     0.000

18      root    localhost:56336 test    Query   643     setup   ALTER TABLE t_07 ADD FULLTEXT INDEX `MarvãO_ftidx1` ( col_text ), LOCK = SHARED /* E_R Thread3 QNO     0.000

19      root    localhost:56340 test    Query   659     Unlocking tables        ALTER TABLE t_02 DROP INDEX `Marvão_ftidx1`, ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK    0.000

20      root    localhost:56342 test    Query   657     Unlocking tables        ALTER TABLE t_04 DROP INDEX `Marvão_ftidx1`, ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK    0.000

21      root    localhost:56344 test    Query   657     Unlocking tables        ALTER TABLE t_05 DROP INDEX `MarVão_ftidx1`, ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK    0.000

23      root    localhost:56348 test    Query   659     committing alter table to storage engine        ALTER TABLE t_03 DROP INDEX `Marvão_ftidx1`, ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK    0.000

24      root    localhost:56350 test    Query   653     Unlocking tables        ALTER TABLE t_08 DROP INDEX `MarvãO_ftidx1`, ADD FULLTEXT INDEX `MArvão_ftidx1` ( col_text ), LOCK    0.000

25      root    localhost:56352 test    Query   659     preparing for alter table       ALTER TABLE t_10 DROP INDEX `MArvão_ftidx1`, ADD FULLTEXT INDEX `MarVão_ftidx1` ( col_text ), LOCK    0.000

26      root    localhost:56354 test    Query   659     committing alter table to storage engine        ALTER TABLE t_01 DROP INDEX `MArvão_ftidx1`, ADD FULLTEXT INDEX `Marvão_ftidx1` ( col_text ), LOCK    0.000

114     root    localhost       NULL    Query   0       init    SHOW PROCESSLIST        0.000

RQG declares "deadlock" in that case. 

The problem reported here might be a sibling of already reported bugs where

server do not react on "mysqladmin ... shutdown" or SIGTERM.

Roughly the same effects was observed on 10.3 too.

In the moment I do not know if the Storage engine InnoDB or the server is guilty.

So please adjust the assignee if necessary.