-
Marko Mäkelä authored
This bug was a regression caused by MDEV-12698. On non-leaf pages, the delete-mark flag in the node pointer records is basically garbage. (Delete-marking only makes sense at the leaf level anyway. The purpose of the delete-mark is to tell MVCC, locking and purge that a leaf-level record does not exist in the READ UNCOMMITTED view, but it used to exist.) Node pointer records and non-leaf pages are glue that attaches multiple leaf pages to an index. This glue is supposed to be transparent to the transactional layer. When a page is split, InnoDB creates a node pointer record out of the child page record that the cursor is positioned on. The node pointer record for the parent page will be a copy of the child page record, amended with the child page number. If the child page record happened to carry the delete-mark flag, then the node pointer record would also carry this flag (even though the flag makes no sense outside child pages). (On a related note, for the first node pointer record in the first node pointer page of each tree level, if the MIN_REC_FLAG is set, the rest of the record contents (except the child page number) is basically garbage. From this garbage you could deduce at which point the child was originally split.) page_scan_method_t: Replace with bool, as there are only 2 values. dict_stats_scan_page(): Replace the parameter scan_method with is_leaf. Ignore the bogus (garbage) delete-mark flag if !is_leaf.
e7bf8bca