Comment 4 for bug 1121072

This handling is very much non-redundant for XtraBackup, as MLOG_FILE_DELETE is indeed replayed there.

See bug 1079700 fix description at [1].

However, it raises the question of why the existing handling of treating recovery updates to deleted tablespaces in buf_read_page_low() was not enough for bug 1079700 purposes. This question is best discussed there.

Marking this bug as invalid for XtraBackup. It is still valid for Percona Server.

"Another change necessitated by the patch is ignoring deleted tablespaces
on recovery, which has been implemented in XB patches to
recv_apply_hashed_log_recs(). After MLOG_FILE_DELETE is replayed on
recovery and the underlying file is deleted, possible updates to the
same tablespace done before deleting the tablespace are left in the redo
log. They will be ignored by the recovery code. This can never cause any
problems for server, because file creation/removal is done immediately,
so on recovery InnoDB detects missing tablespace files and does not the
corresponding log records to the hash table (see the first lines in
recv_add_to_hash_table). The situation is different with XtraBackup: the
underlying file will be present when recovery starts, but then get
deleted when MLOG_FILE_DELETE is replayed, i.e. after all log records
from the current batch have been added to the hash table. As a result,
log records corresponding to the deleted tablespace are ignore, but are
still left in the hash table, so recv_apply_hashed_log_recs() hangs
forever waiting for recv_sys->n_addrs to become zero. This was also
possible with XtraBackup before this fix, i.e. when a tablespace is
removed after it has been copied by XtraBackup. This fix just makes this
condition more likely to occur, as we always copy all tablespaces rather
than ignore those removed before the copy operation is tarted.

To fix the above case, we also check for deleted tablespaces in
recv_apply_hashed_log_recs(). Those corresponding to previously deleted
tablespaces are marked as processed and recv_sys->n_addrs is decremented
accordingly to not leave spurious unprocessed log records in the hash