The FIL_PAGE_TYPE of the page on which the assertion fails is 1. That is an invalid value. However, buf_page_t::state() for the block descriptor is FREED, that is, it might not actually be a valid page and the check should perhaps not be evaluated. The block had been freed here:

#2  0x00005633fe0ebea9 in buf_page_t::set_freed (this=..., prev_state=..., 

    count=...) at /data/MDEV-31386/10.9/storage/innobase/include/buf0buf.h:737

#3  0x00005633fe0d41c4 in recv_recover_page (block=..., mtr=..., recs=..., 

    space=..., init=...)

    at /data/MDEV-31386/10.9/storage/innobase/log/log0recv.cc:3328

#4  0x00005633fe0d5c42 in IORequest::fake_read_complete (this=..., offset=...)

    at /data/MDEV-31386/10.9/storage/innobase/log/log0recv.cc:3467

#5  0x00005633fe16955b in fake_io_callback (c=...)

    at /data/MDEV-31386/10.9/storage/innobase/os/os0file.cc:3434

Deeper analysis will be needed to understand whether the assertion should be simply skipped after buf_page_t::set_freed(), or this is a sign of actual data corruption.

The only log record that was applied for the page was FREE_PAGE. Because the contents of freed page frames do not matter, the page frame was never initialized. In all other cases (there had been an INIT_PAGE record, or the page was read from the file system), the buffer page contents should be valid.

In this special case, we could actually avoid invoking the recovery altogether, to save some memory. Even if innodb_immediate_scrub_data_uncompressed had been set (it was at the default value OFF here) or the data file used sparse files with page_compressed, recovery could theoretically duplicate the logic of buf_page_t::flush() and avoid allocating a buffer block.

I think that we should simply fix i_s_innodb_buffer_page_get_info() so that it will ignore the contents of freed blocks.

I tried to come up with a simple test to reproduce this bug, but failed. Here is one attempt; I also tested a kill+restart after DROP INDEX:

--source include/have_innodb.inc

--source include/have_sequence.inc

set global innodb_file_per_table=0;

create table t engine=innodb select * from seq_1_to_1000000;

drop table t;

--source include/kill_mysqld.inc

--source include/start_mysqld.inc

SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE;

elenst, can you please test the following fix?

diff --git a/storage/innobase/handler/i_s.cc b/storage/innobase/handler/i_s.cc

index 3cb51f5e15d..b00308d7e51 100644

--- a/storage/innobase/handler/i_s.cc

+++ b/storage/innobase/handler/i_s.cc

@@ -3882,7 +3882,7 @@ i_s_innodb_buffer_page_get_info(

 	page_info->state = bpage->state();

-	if (page_info->state < buf_page_t::FREED) {

+	if (page_info->state < buf_page_t::UNFIXED) {

 		page_info->page_type = I_S_PAGE_TYPE_UNKNOWN;

 		page_info->compressed_only = false;

 	} else {

There have been not nearly enough occurrences of the failure in my tests to come up with any statistics and thus to make a conclusion that the problem was solved if the failure doesn't occur in N attempts.
As usual in such cases, the only reliable solution is that mleich extends his tests to make them hit the problem based on marko 's analysis of (possible) circumstances which lead to it, runs sufficient amount of targeted tests on the unfixed code to establish the statistical baseline, and then runs them on the fixed code.

I have some ideas for reproducing this bug in the 10.9 branch:

1. Kill the server soon after the completion of an operation that would free lots of pages:
   • DROP INDEX
   • BEGIN; INSERT many_rows; ROLLBACK;
   • DROP TABLE of a table that had been created in the system tablespace
2. Remove any ib_buffer_pool file.
3. Start up with innodb_force_recovery=2 and possibly a larger innodb_buffer_pool_size than the one that was used in the killed server. The idea is to avoid the eviction of any buf_page_t::FREED pages after recovery.
4. As soon as possible after startup, execute a query that accesses all rows of INFORMATION_SCHEMA.INNODB_BUFFER_PAGE.

I have some replay test. 6 replays on 130 repetitions of the test.
origin/10.9 878a86f2764289e6679065b334fef8ca56786948 2023-06-07T14:32:46+03:00
Hence ~ 1000 repetitions of that test without any replay of the problem on some source tree with fix ensure that either

• the problem is really fixed
  or
• the fix has reduced the likelihood to show up drastic.

No replay on origin/10.9 878a86f2764289e6679065b334fef8ca56786948 2023-06-07T14:32:46+03:00 + the patch from above.

As part of fixing this, I removed the test innodb.innodb_defragment_fill_factor, because it would depend on information on freed pages being available in information_schema.innodb_buffer_page. The feature that the test is related to was removed in MDEV-30545.