The initial implementation of MDEV-8139 introduced a condition to prevent violations of the write-ahead-logging protocol:

static void buf_flush_freed_pages(fil_space_t *space)

{

  ut_ad(space != NULL);

  if (!srv_immediate_scrub_data_uncompressed && !space->is_compressed())

    return;

  lsn_t flush_to_disk_lsn= log_sys.get_flushed_lsn();

  std::unique_lock<std::mutex> freed_lock(space->freed_range_mutex);

  if (space->freed_ranges.empty()

      || flush_to_disk_lsn < space->get_last_freed_lsn())

  {

    freed_lock.unlock();

    return;

  }

But, there is no logic around log checkpoints that would ensure that all fil_space_t::freed_ranges will be scrubbed before the checkpoint is advanced.

The simplest fix would be to invoke log_write_up_to(flush_to_disk_lsn, true) while not holding any mutex. This should not incur much of a performance regression, given that this code is not enabled by default.

It would be very hard to create a regression test for this, because there is no easy way to control log writes, especially after improvements like MDEV-24341 and MDEV-27774. I found this bug while diagnosing MDEV-31234.

I checked failures of the test innodb.innodb_scrub on the CI system. The majority of them are related to hangs while waiting for all history to be purged. I did not find an example where scrubbing a data page would have been missed.