Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-32552

Write-ahead logging is broken for freed pages




      MDEV-15528 implemented an optimization: pages that have been marked as freed will not be written back to data files. Unfortunately, this optimization violates the write-ahead logging protocol, because we fail to ensure that all log up to the freeing of the page has been durably written before we elide the write of the data page.

      If InnoDB is killed before the log for freeing a page was durably written, crash recovery could fail because it would read an older version of the data page and attempt to apply log records that are for a newer version of the page.

      We can observe some occasional recovery test failures that could be explained by this, such as the following:

      10.6 56c9b0bca0576985c31f20b46dcb060a

      atomic.alter_table 'innodb'              w1 [ fail ]  Found warnings/errors in server log file!
              Test ended at 2023-01-10 11:25:39
      2023-01-10 11:24:24 0 [ERROR] InnoDB: Corrupted page [page id: space=228, page number=0] of datafile './test/t1.ibd' could not be found in the doublewrite buffer.

      The scenario that I have in mind would be fixed by making buf_page_free() mark the freed block as modified in the mini-transaction, and buf_flush_page() check that everything up to the FIL_PAGE_LSN of the page has been durably written to the redo log. After first change, that field would be updated by buf_flush_note_modification(), which is invoked by mtr_t::commit().


        Issue Links



              marko Marko Mäkelä
              marko Marko Mäkelä
              0 Vote for this issue
              1 Start watching this issue



                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.