the same on 10.4 http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-centos6-x86/builds/1380/steps/mtr/logs/stdio

I think that the test is inaccurate. Maybe the page replacement is not always guaranteed, and we should insert more data to guarantee page eviction from the buffer pool?

One thing that the test is definitely missing is a read of the table t2. It reads from t1 after hopefully evicting some of its pages by populating another table t2.

The buffer pool size is at the minimum (5MiB). That would host at most 320 pages at the default innodb_page_size=16k.

The test is inserting 2×8192 rows into 3 tables. The leaf-level record payload size is about 6+6+7+200+200 and 6+6+7+100+200+200 bytes (419 and 519 bytes). That is 4,251,648 bytes for the larger table. With the page header and trailer overhead, maybe it should exceed the 5,242,880 bytes?

I was able to repeat this problem very easily when I was diagnosing MDEV-23304. So, I should be able to stabilize this test.

I pushed a fixup to 10.2 that I hope will make the failure disappear. But, I was unable to reproduce this failure in my environment today. Therefore, I am not closing this bug yet.

This test still occasionally fails. If I ignore all the crashes on POWER due to a Linux kernel bug (MDEV-30728) there have been a few failures like this:

encryption.innodb_encrypt_temporary_tables 'cbc,innodb,strict_full_crc32' w1 [ fail ]

        Test ended at 2023-10-30 13:33:43

CURRENT_TEST: encryption.innodb_encrypt_temporary_tables

--- /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.result	2023-10-30 12:36:19.000000000 +0000

+++ /home/buildbot/buildbot/build/mariadb-10.4.32/mysql-test/suite/encryption/r/innodb_encrypt_temporary_tables.reject	2023-10-30 13:33:40.257265525 +0000

@@ -15,7 +15,7 @@

 SELECT variable_value > @old_encrypted FROM information_schema.global_status

 WHERE variable_name = 'innodb_encryption_n_temp_blocks_encrypted';

 variable_value > @old_encrypted

-1

+0

 SELECT variable_value > @old_decrypted FROM information_schema.global_status

 WHERE variable_name = 'innodb_encryption_n_temp_blocks_decrypted';

 variable_value > @old_decrypted

mysqltest: Result content mismatch

I recently found out that information_schema.global_status.variable_value is a character string, not an integer. An explicit cast to integer is needed if we want integer comparison semantics instead of character string (9<10 but '9'>'10').