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 | |
| 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.
| -rw-r--r-- | mysql-test/suite/innodb/disabled.def | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/mysql-test/suite/innodb/disabled.def b/mysql-test/suite/innodb/disabled.def index 35c941f8af7..4484417afce 100644 --- a/mysql-test/suite/innodb/disabled.def +++ b/mysql-test/suite/innodb/disabled.def @@ -11,3 +11,4 @@ ############################################################################## create-index-debug : MDEV-13680 InnoDB may crash when btr_page_alloc() fails +innodb_force_recovery_rollback : MDEV-22889 InnoDB occasionally breaks ACID |