MySQL Bugs: #109079: InnoDB: The B-tree of index GEN_CLUST

Bug #109079	InnoDB: The B-tree of index GEN_CLUST_INDEX is corrupted
Submitted:	14 Nov 2022 15:03	Modified:	13 Dec 2022 12:33
Reporter:	Fabien Bagard	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S4 (Feature request)
Version:	5.7.39-log, 8.0.28	OS:	Debian (Not tested on other OSes)
Assigned to:		CPU Architecture:	x86 (Not tested on other architectures)

Description:
False report of a corrupted index. It can be GEN_CLUST_INDEX if the table has no primary key or PRIMARY index if the table has a primary key.

Without primary key defined we have `InnoDB: The B-tree of index GEN_CLUST_INDEX is corrupted` and key gets corrupted with "`h` char(237) NOT NULL"

With primary key : `InnoDB: The B-tree of index PRIMARY is corrupted` and key gets corrupted with "`h` char(238) NOT NULL"

Having one less CHAR somewhere in the table definition and key corruption is not reported anymore.

Doubling the number of CHAR and using UTF-16 does not cause the key corruption error message.

How to repeat:
CREATE DATABASE DB; USE DB;

CREATE TABLE `A` (
  `a` char(255),
  `b` char(255),
  `c` char(255),
  `d` char(255),
  `e` char(255),
  `f` char(255),
  `g` char(255),
  `h` char(237)
) ENGINE=InnoDB DEFAULT CHARSET=utf32;

INSERT INTO `A` VALUES ('','','','','','','','');

check table A;

Error message in logs:

[ERROR] InnoDB: Field 3 len is 20, should be 1020; COMPACT RECORD(info_bits=0, 11 fields): {[6]      (0x000000000C04),[6]    `I(0x000000000009),[7]    '  (0x03000001070100),[0+20](0x)(0x000001040000000400000006000000000000030C),[1020]

Hi Mr. Bagard,

Thank you for your bug report.

However, this is not a bug.

It is fully explained in our Reference Manual, since this is InnoDB-specific feature.

Simply, the fixed size of the record is too big. You should convert many of those CHAR columns into VARCHAR.

Not a bug.

Hi,

This change changes behaviour of our InnoDB storage engine. However, issuing a warning or error after CREATE TABLE statement would make lot's of sense .....

Verified as a feature request.