Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6.6
Description
origin/bb-10.6-release 6dd07fbd042132729e5dea0a6a9b35f07a33e9e5 2022-02-03T16:51:08+02:00
|
|
Scenario:
|
1. Start the server (default storage engine is InnoDB)
|
2. On session runs SET INNODB_STRICT_MODE = 0 ;
|
3. The same session runs in some roughly endless loop:
|
DROP TABLE t1 ; CREATE TABLE t1 (col1 INT) ROW_FORMAT=COMPRESSED ;
|
4. During 3. is ongoing the server gets killed (SIGKILL)
|
5. Restart with success
|
6. CHECK TABLE t1 with success
|
7. OPTIMIZE TABLE t1 harvests the following output in RQG
|
'test.t1', 'optimize', 'note', 'Table does not support optimize, doing recreate + analyze instead'
|
'test.t1', 'optimize', 'error', 'Table storage engine \'InnoDB\' does not support the create option \'ROW_TYPE\''
|
|
Why
|
- does the OPTIMIZE fail with some create option which is nowhere set?
|
- is ROW_TYPE mentioned. I cannot find it in https://mariadb.com/kb/en/create-table
|
|
Observations:
|
- SHOW CREATE TABLE t1 shows the expected
|
CREATE TABLE `t1` (`col1` int(11) DEFAULT NULL)
|
ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED'
|
after the CHECK TABLE (6. above)
|
- No replay of the problem in case of
|
- ROW_FORMAT in (COMPACT,REDUNDANT,DYNAMIC)
|
or
|
- INNODB_STRICT_MODE sticks to the default which is 1
|
|
pluto:/data/results/1675431713/TBR-1775B/_RR_TRACE_DIR=./1/rr/ rr replay --mark-stdio
|
Attachments
Issue Links
- relates to
-
MDEV-22367 Remove write support for ROW_FORMAT=COMPRESSED
-
- Closed
-
-
MDEV-29983 Deprecate innodb_file_per_table
-
- Closed
-
-
MDEV-29985 Remove the parameter innodb_file_per_table
-
- Stalled
-
If this is like the case what I analyzed earlier, it should be like this (untested mtr test):
--source include/have_innodb.inc
--error …
Due to innodb_file_per_table=0, the ROW_FORMAT=COMPRESSED would be refused by InnoDB but stored in the t1.frm file. The innodb_strict_mode=OFF allows the table to be created in this way. Because the attribute was stored in the t1.frm file, it would be part of the table definition passed to InnoDB in any subquent table-rebuilding ALTER TABLE or OPTIMIZE TABLE. If innodb_file_per_table=0 is still set, then the table would not be moved from the InnoDB system tablespace to a t1.ibd file, and hence the ROW_FORMAT=COMPRESSED cannot be fulfilled. If innodb_strict_mode is enabled (it is by default), this would result in the described error.
TRUNCATE could be more lenient about this, because we wanted to avoid any change of behavior due to
MDEV-13564.