summaryrefslogtreecommitdiff
path: root/sql/sql_prepare.cc
diff options
context:
space:
mode:
authorMarko Mäkelä <marko.makela@mariadb.com>2020-06-14 10:18:07 +0300
committerMarko Mäkelä <marko.makela@mariadb.com>2020-06-14 10:26:42 +0300
commit2cd6afb08372dac6220f69fbb6b44d2d2e964cfc (patch)
tree4cada55afa8c3d86f375271892e59f32458743f8 /sql/sql_prepare.cc
parentb68f1d847f1fc00eed795e20162effc8fbc4119b (diff)
downloadmariadb-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 'sql/sql_prepare.cc')
0 files changed, 0 insertions, 0 deletions