The test case innodb.innodb_force_recovery_rollback that was added for
MDEV-21217 should have only two possible outcomes for the locking SELECT statement:
- The statement is blocked if the fix of
MDEV-21217is missing, and the test will eventually fail with a lock wait timeout
- The lock conflict will ensure that the statement will execute after the rollback has completed, and an empty table will be observed.
What occasionally happens is that the locking SELECT will return nonempty contents for the table. I was not able to repeat it in my local environment, but it did occur on buildbot for several branches and builders.
Such breakage of ACID is serious, and we must find and fix the reason.
I believe that we must execute something like
so that the server after the restart runs under rr record, so that we will get an execution trace of the failure for debugging.
Here is an example of a failure: http://buildbot.askmonty.org/buildbot/builders/kvm-zyp-opensuse150-amd64/builds/3589/steps/mtr/logs/stdio
Apparently, only the Isolation is being being violated: the locking read will return all 1000 records that the incomplete transaction had inserted.
It is also theoretically possible that the incomplete transaction that inserted those 1,000 records was unexpectedly committed when the server was killed.