[MDEV-20584] Clearing delete-mark on R-tree pages does not appear crash-safe Created: 2019-09-13  Updated: 2020-02-24  Resolved: 2020-02-24

Status: Closed
Project: MariaDB Server
Component/s: mariabackup, Storage Engine - InnoDB
Affects Version/s: 10.2.2, 10.3.0, 10.4.0
Fix Version/s: 10.5.2

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: GIS, corruption, recovery, upstream

Issue Links:
Relates
relates to MDEV-12353 Efficient InnoDB redo log record format Closed

 Description   

In the functions rtr_page_copy_rec_list_end_no_locks() and rtr_page_copy_rec_list_start_no_locks(), no redo log is being written for clearing a bit in the R-tree page:

				if (rec_get_deleted_flag(cur1_rec,
					dict_table_is_comp(index->table))) {
					goto next;
				} else {
					/* We have two identical leaf records,
					skip copying the undeleted one, and
					unmark deleted on the current page */
					btr_rec_set_deleted_flag(
						cur_rec, NULL, FALSE);
					goto next;
				}

This call is also passing page_zip=NULL, which ought to cause UNIV_ZIP_DEBUG assertion failures when using ROW_FORMAT=COMPRESSED. But, that parameter was changed in MySQL 5.7.5 exactly to address the failure of a UNIV_ZIP_DEBUG check. There code change is associated with a test case change, so we have some hope that the failure is repeatable.

The purpose of this call is unclear. It was added as part of introducing InnoDB R-tree index support.

The bug was found as part of implementing a purely physical redo log record format in MDEV-12353.



 Comments   
Comment by Marko Mäkelä [ 2020-02-24 ]

With the MDEV-12353 redo log format in MariaDB 10.5.2, the operation ought to be crash-safe.

Generated at Thu Feb 08 09:00:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.