Test innodb.percona_changed_page_bmp_crash is unstable

[Laurynas Biveinis]

On 5.5 trunk:

innodb.percona_changed_page_bmp_crash w1 [ fail ]
        Test ended at 2016-08-11 18:28:33

CURRENT_TEST: innodb.percona_changed_page_bmp_crash
--- /mnt/workspace/percona-server-5.5-trunk/BUILD_TYPE/debug/Host/centos7-64/mysql-test/suite/innodb/r/percona_changed_page_bmp_crash.result 2016-08-11 21:03:00.493295289 +0300
+++ /mnt/workspace/percona-server-5.5-trunk/BUILD_TYPE/debug/Host/centos7-64/mysql-test/suite/innodb/r/percona_changed_page_bmp_crash.reject 2016-08-11 21:28:33.152643921 +0300
@@ -31,5 +31,4 @@
 INSERT INTO t1 VALUES (1),(2),(3),(4),(5);
 ib_modified_log_1
 ib_modified_log_2
-ib_modified_log_3
 DROP TABLE t1, t2;

mysqltest: Result length mismatch

safe_process[28083]: Child process: 28084, exit: 1

One way this can happen is when ib_modified_log_2* is zero-sized at the time of the last server restart. Then it would get reused instead of rotated. There is no protection against it being zero sized as there is no write workload before the resize, the only way it can get bitmap data written is by crash recovery, but the crashed instance might have written everything already.

[Laurynas Biveinis (laurynas-biveinis)]

     https://github.com/percona/percona-server/pull/819
     https://github.com/percona/percona-server/pull/820
     https://github.com/percona/percona-server/pull/821

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2171