Marko Mäkelä added a comment - 2023-01-19 15:01 I do not see how the change buffer code could return DB_FAIL up to the caller. The cause of this crash remains a mystery.

Marko Mäkelä added a comment - 2023-02-08 15:36 I can reproduce this behaviour on 10.6 by modifying buf_LRU_free_page() so that it would attempt to evict modified pages of temporary tables. There obviously is some flaw with that modification, but it would reproduce this error in a couple of tests that exercise temporary tables. In other words, we are attempting some operation on a corrupted page, getting DB_FAIL and not handling it in a consistent fashion (I suppose, by initiating a rollback).

Marko Mäkelä added a comment - 2023-02-08 16:05 In my case (caused by a buggy code change that I am working on), we are reading a page that has been filled by NUL bytes, and returning DB_FAIL due to that. Other corruption detected by that function results in a different error code: diff --git a/storage/innobase/buf/buf0buf.cc b/storage/innobase/buf/buf0buf.cc index 5c81e34856b..7b18906f395 100644 --- a/storage/innobase/buf/buf0buf.cc +++ b/storage/innobase/buf/buf0buf.cc @@ -3600,7 +3600,7 @@ dberr_t buf_page_t::read_complete(const fil_node_t &node) else if (read_id == page_id_t(0, 0)) { /* This is likely an uninitialized (all-zero) page. */ - err= DB_FAIL; + err= DB_PAGE_CORRUPTED; goto release_page; } else if (!node.space->full_crc32() &&

Marko Mäkelä added a comment - 2023-02-08 16:22 The DB_FAIL return value was added to that function in MDEV-13542 . I would not call this bug a regression of that, but an omission of that fix. Before MDEV-13542 , we would typically simply crash due to the corrupted page.

Marko Mäkelä added a comment - 2023-02-09 07:58 The special return value is needed so that fil_aio_callback() can avoid reporting an error when read-ahead is covering an unallocated page. The error code needs to be mapped for synchronous reads, in buf_read_page_low() .