Aleksey Midenkov added a comment - 2019-08-10 11:07 trx_id_future is unstable in 10.3: http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos73-ppc64/builds/9644 CURRENT_TEST: innodb.trx_id_future --- /usr/share/mysql-test/suite/innodb/r/trx_id_future.result 2019-07-27 08:07:27.000000000 +0000 +++ /dev/shm/var/2/log/trx_id_future.reject 2019-07-27 11:56:36.350175707 +0000 @@ -8,6 +8,5 @@ call mtr.add_suppression("\\[Warning\\] InnoDB: A transaction id in a record of table `test`\\.`t1` is newer than the system-wide maximum"); SELECT * FROM t1; a -Warnings: -Warning 1642 InnoDB: Transaction id in a record of table `test`.`t1` is newer than system-wide maximum. +1 DROP TABLE t1;

Marko Mäkelä added a comment - 2019-08-13 09:19 On 10.1, the test fails on big-endian environments, because innodb_checksum_algorithm=crc32 wrongly assumes little-endian byte order. I think that it is easiest to change the test to compute the dummy innodb_checksum_algorithm=none checksum on 10.1, and null-merge that change to 10.2. The problem on 10.3 and 10.4 should be something else, possibly related to MDEV-12288 . I will investigate. I was unable to reproduce any failure on 10.2 locally, and the cross-reference did not find any either.

Marko Mäkelä added a comment - 2019-08-13 12:44 The issues were specific for the test only. No code changes were made. On 10.1, we will skip the test on big-endian systems, because the implementation of innodb_checksum_algorithm=crc32 wrongly assumes little-endian byte order. On 10.3 and later, we must ensure that purge has run into completion before we shut down the server and corrupt the transaction identifier, so that the corruption will remain after restart.