[MDEV-17881] Assertion failure in cmp_dtuple_rec_with_match_bytes after instant ADD COLUMN Created: 2018-11-30  Updated: 2018-12-28  Resolved: 2018-11-30

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3.2, 10.4.0
Fix Version/s: 10.4.1, 10.3.12

Type: Bug Priority: Critical
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-11369 Instant add column for InnoDB Closed
Relates
relates to MDEV-18095 InnoDB assertion failure when access ... Closed

 Description   

The special flag REC_INFO_MIN_REC_FLAG used to be only set on the first record in the leftmost node pointer page of each level of the tree. It was never set on leaf pages.

MDEV-11369 Instant ADD COLUMN in MariaDB Server 10.3 repurposed the flag to identify a hidden metadata record, which is stored in the first record on the leftmost leaf page.

If the adaptive hash index points to records in the leftmost leaf page after instant ADD COLUMN (or MDEV-15562 instant DROP COLUMN in 10.4.0), we would have such a metadata record in the table, an assertion could fail when trying to validate the index record:

mysqld: /mariadb/10.4/storage/innobase/rem/rem0cmp.cc:799: int cmp_dtuple_rec_with_match_bytes(const dtuple_t*, const rec_t*, const dict_index_t*, const ulint*, ulint*, ulint*): Assertion `!(0x10UL & rec_get_info_bits(rec, rec_offs_comp(offsets)))' failed.

I only repeated this in a 10.4-based development tree. Due to the highly nondeterministic nature of the adaptive hash index, it could be difficult to construct a deterministic test case for this.


Generated at Thu Feb 08 08:39:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.