Some preliminary results (this text is under construction):

1. Especially RQG concurrency tests usually do not check result sets/messages returned by the server.

    Reason for that:

    The shape of result sets cannot be predicted because there is concurrent data modifying DML up till DDL.

    The same applies to some serious extend for success and fail of single SQL's.

    Some queries get killed, others fail when the server resolves a deadlock or some fail because an object

    like table/column/key/... does for some limited timespan already exists or does no more exists.

    Hence the range of most probably to be tolerated errors returned by the server is partially big.

2. CHECK TABLE  for InnoDB is capable to detect certain (but most probably not all) structural defects.

     But it has some properties which are quite problematic to exploit or handle right inside RQG.

     - It could fail from a broad range of valid reasons like other SQL (see 1.) too.

     - When detecting some structural defect when executing CHECK TABLE the server seems to write all time a 

       corresponding entry in the server error log and than

        - shutdown to prevent the error propagation in case the defect is classified as that serious

        or

        - mark the table or index ... as corrupt, return a warning and ERROR_CODE 0 in case the defect is classified as not that serious

          Exact this happens for example in the MTR based test added by Marko to MDEV-20066.

          CHECK TABLE t1;

          Table   Op      Msg_type        Msg_text

           test.t1 check   Warning InnoDB: Index 'c' contains 1 entries, should be 0.

           test.t1 check   error   Corrupt

                   no shutdown to prevent error propagation

           But unfortunately just here the defect is extreme serious.

3.  The timespan between maybe causing a structural defect and detecting it via CHECK TABLE or similar

      is critical.  In case there is some other SQL between (maybe concurrent session) than we have some

      high likelihood to end up with some assert caused instead (see MDEV-20066 bug description on top).

4. The detection of the structural defect via CHECK TABLE must be immediate followed by some abort of

     the RQG test. Otherwise SQL causing an assert could be between or we waste machine time ...

5. Periodic Reporters work all 10s. This timespan is too long except we reduce the amount of SQL between

     which than wastes resources ...

6. Validators get executed after each query (maybe short statement sequence). That is sufficient frequent

     but CHECK TABLE run by that validator commits most probably any ongoing transaction.

     And this effect might be too intrusive.

    When going with threads > 1 we will get the additional effect that the heavy locking caused by

    CHECK TABLE will have some strong impact on the concurrent DDL/DML.

    heavy locking.

Weaknesses fixed/checks extended

1. The errors 1712 (ER_INDEX_CORRUPT) and 1817 (ER_INNODB_INDEX_CORRUPT) get now mapped to the error class STATUS_DATABASE_CORRUPTION.

     Therefore RQG will bring the test quite fast to an end.

     Expected impact:

     The fraction of tests which end with some bad status != STATUS_DATABASE_CORRUPTION even though having e hit a corruption should become rare.

 2. Extend the execution of statements and handling of results sets inside of lib/GenTest/Executor/MySQL.pm.

      In case the execution of some statement passed and it was a CHECK TABLE than check the result set. In case the information within the result set

      points to data corruption inside of an InnoDB table than set STATUS_DATABASE_CORRUPTION.

     The standard reaction of RQG will be than:

     Abort immediate the test, cleanup and report STATUS_DATABASE_CORRUPTION.