Affects Version/s: None
Fix Version/s: None
**Reported in Launchpad by Laurynas Biveinis last update 20-01-2018 08:00:16
XtraDB and XtraBackup patch buf_read_page_low() and buf_read_recv_pages() to handle DB_TABLESPACE_DELETED error for the data page reads during recovery by looping over the hashed log recs and removing any belonging to this tablespace. This patch has been sent upstream as http://bugs.mysql.com/bug.php?id=43948.
I believe this patch is not required anymore, or never was required in the first place. It is possible that it appeared to be required for XtraBackup before the recent data dictionary handling improvements.
[10 Feb 11:13] Laurynas Biveinis
I don't see how the described situation may ever occur, at least with the current trunks. The patch handles the situation of recovery trying to read a page from a deleted tablespace into the buffer pool. But recovery initializes the fil_space structures by looking at the actual ibds on the disk (fil_load_single_table_tablespaces()) and log records are only stored to the recovery hash table if the tablespace is found to exist at the log parse time (recv_add_to_hash_table() calls fil_tablespace_deleted_or_being_deleted_in_mem()).
Thus a tablespace should somehow disappear between the fil_load_single_table_tablespaces() and some recv_add_to_hash_table() call with a redo log rec for that tablespace. One way for this to happen would be to replay a MLOG_FILE_DELETE, but these aren't replayed during the crash recovery, and even if there is such rec in the redo log, its corresponding ibd is already deleted, meaning that fil_load_single_table_tablespaces() would not load it in the first place.
I'd replace the Yasufumi's patch with something like
ut_ad(!recv_recovery_is_on() || *err != DB_TABLESPACE_DELETED);
to be sure.