diff options
| author | Marko Mäkelä <marko.makela@mariadb.com> | 2020-06-14 10:18:07 +0300 |
|---|---|---|
| committer | Marko Mäkelä <marko.makela@mariadb.com> | 2020-06-14 10:26:42 +0300 |
| commit | 2cd6afb08372dac6220f69fbb6b44d2d2e964cfc (patch) | |
| tree | 4cada55afa8c3d86f375271892e59f32458743f8 /tests | |
| parent | b68f1d847f1fc00eed795e20162effc8fbc4119b (diff) | |
| download | mariadb-git-2cd6afb08372dac6220f69fbb6b44d2d2e964cfc.tar.gz | |
MDEV-22889: Disable innodb.innodb_force_recovery_rollback
The test case that was added for MDEV-21217
(commit b68f1d847f1fc00eed795e20162effc8fbc4119b)
should have only two possible outcomes for the locking SELECT statement:
(1) The statement is blocked, and the test will eventually fail
with a lock wait timeout. This is what I observed when the
code fix for MDEV-21217 was missing.
(2) The lock conflict will ensure that the statement will execute
after the rollback has completed, and an empty table will be observed.
This is the expected outcome with the recovery fix.
What occasionally happens (in some of our CI environments only, so far)
is that the locking SELECT will return all 1,000 rows of the table that
had been inserted by the transaction that was never supposed to be
committed. One possibility is that the transaction was unexpectedly
committed when the server was killed.
Let us disable the test until the reason of the failure has been
determined and addressed.
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions