[MDEV-20194] Warnings inconsistently issued upon CHECK on table from older versions - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.2(EOL), 10.3(EOL)
Fix Version/s: 10.3.35, 10.4.25, 10.5.16, 10.6.8
Component/s: Admin statements, Storage Engine - InnoDB
Labels:
None

Description

Note: I'm fine with closing it as not a bug as long as all aspects of the new behavior are considered and confirmed to be expected. It was discussed a little on slack as a probably innocent consequence of ~~MDEV-19292~~ fix, but I am not sure there was a final conclusion.

Here is an example of the table:

CREATE TABLE t1 (

  `c01` int(10) unsigned zerofill NOT NULL DEFAULT 0000000000,

  `c03` varchar(1024) NOT NULL DEFAULT '',

  `c04` timestamp(6) NOT NULL DEFAULT current_timestamp(6) ON UPDATE current_timestamp(6),

  `c06` double(16,8) DEFAULT NULL COMMENT 'Percentage',

  `c07` date DEFAULT NULL,

  `c12` varchar(64) GENERATED ALWAYS AS (concat(`c09`,' ',`c10`)) VIRTUAL,

  `c05` longblob NOT NULL DEFAULT '',

  `c11` varchar(64) GENERATED ALWAYS AS (concat(`c09`,' ',`c10`)) PERSISTENT,

  `c08` text DEFAULT '',

  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,

  `c02` char(3) NOT NULL DEFAULT '',

  `c10` bigint(20) DEFAULT NULL COMMENT 'Y',

  `c09` bigint(20) DEFAULT NULL COMMENT 'X',

  PRIMARY KEY (`id`),

  UNIQUE KEY `idx1` (`c01`,`c02`),

  KEY `idx2` (`c05`(128))

) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT;

Server options: --innodb-compression-algorithm=none --innodb-page-size=4K, otherwise defaults.

The table gets created on a pre-~~MDEV-19292~~ server with without any warnings (on a post-~~MDEV-19292~~ server it gets rejected).
When a post-~~MDEV-19292~~ server starts on the old datadir, CHECK TABLE t1 produces the warning:

10.2 fc77a66c
+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
\| Table \| Op \| Msg_type \| Msg_text \|
+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
\| test.t1 \| check \| Warning \| Row size too large (> 1982). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline. \|
\| test.t1 \| check \| status \| OK \|
+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

First, it's unclear whether ~~MDEV-19292~~ patch was supposed to affect REDUNDANT / COMPACT tables at all.

Secondly, the warning, if it's true, could have been helpful if it was reliable; but it is only issued on the first opening of the table:

MariaDB [test]> check table t1;

+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| Table   | Op    | Msg_type | Msg_text                                                                                                                                                                                            |

+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| test.t1 | check | Warning  | Row size too large (> 1982). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline. |

| test.t1 | check | status   | OK                                                                                                                                                                                                  |

+---------+-------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

2 rows in set (0.005 sec)

MariaDB [test]> check table t1;

+---------+-------+----------+----------+

| Table   | Op    | Msg_type | Msg_text |

+---------+-------+----------+----------+

| test.t1 | check | status   | OK       |

+---------+-------+----------+----------+

1 row in set (0.005 sec)

Which makes it fairly useless.

And finally, the error log gets a different strange-looking warning instead:

2019-07-28  0:57:51 140189814937344 [Warning] InnoDB: Cannot add field `c08` in table `test`.`t1` because after adding it, the row size is 2484 which is greater than maximum allowed size (1982) for a record on index leaf page.

Attachments

Issue Links

blocks

MDEV-20400 Implement a way to query an InnoDB table max row size

Open

includes

MDEV-20949 Stop performing unnecessary maximum row size check for DML

Closed

relates to

MDEV-19292 "Row size too large" error when creating table with lots columns when row format is DYNAMIC or COMPRESSED

Closed

MDEV-20000 Consider adopting innodb.innodb_pagesize_max_recordsize from MySQL

Open

MDEV-20400 Implement a way to query an InnoDB table max row size

Open

MDEV-20832 Don't print "row size too large" warnings in error log if innodb_strict_mode=OFF and log_warnings<=2

Closed

MDEV-21261 When performing instant add column, InnoDB ignores innodb_strict_mode for "row size too large" check

Confirmed

MDEV-21624 Unique index length is able to exceed max key length

Closed

MDEV-21748 ASAN use-after-poison in PageBulk::insertPage on table rebuild

Closed

MDEV-23521 Implement an InnoDB row format that can use overflow pages for smaller columns

Open

MDEV-16969 Fix error message as promised in upstream Bug #69336

Open

MDEV-20400 Implement a way to query an InnoDB table max row size

Open

MDEV-20786 MariaDB server writes warnings into errorlog although 'log_warnings=0'

Closed

MDEV-21429 TRUNCATE and OPTIMIZE are being refused due to "row size too large"

Closed

MDEV-22585 Incorrect note being written to the error log when CREATE and ALTER fail due to Row Size Too Large and in all cases for TRUNCATE and OPTIMIZE TABLE.

Open

(10 relates to)

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2019-07-27 22:04

Elena Stepanova made changes - 2019-07-27 22:04

Field	Original Value	New Value
Priority	Minor [ 4 ]	Major [ 3 ]

Elena Stepanova made changes - 2019-07-27 22:13

Labels

affects-tests

Elena Stepanova added a comment - 2019-07-27 23:26

Also, innodb.innodb-32k-crash test non-deterministically produces the same warning:
http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos73-amd64/builds/11353/steps/mtr/logs/stdio

10.3 5e112a26201d4b343df3e401f8695974a8fa852c
innodb.innodb-32k-crash 'innodb' w1 [ fail ]
Test ended at 2019-07-27 13:16:40

CURRENT_TEST: innodb.innodb-32k-crash
--- /usr/share/mysql-test/suite/innodb/r/innodb-32k-crash.result 2019-07-27 11:56:37.000000000 +0000
+++ /dev/shm/var/1/log/innodb-32k-crash.reject 2019-07-27 13:16:40.754215752 +0000
@@ -136,6 +136,8 @@
aa=@h,ba=@h,ca=@h,da=@h,ea=@h,fa=@h,ga=@h,ha=@h,ia=@h,ja=@h,
ka=@h,la=@h,ma=@h,na=@h,oa=@h,pa=@h,qa=@h,ra=@h,sa=@h,ta=@b,ua=@h,
va=@h,wa=@h,xa=@h,ya=@h,za=@h;
+Warnings:
+Warning 139 Row size too large (> 16318). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
BEGIN;
UPDATE t1 SET a=@g,b=@g,c=@g,d=@g,e=@g;
UPDATE t1 SET f=@g,g=@g,h=@g,i=@g,j=@g;

mysqltest: Result length mismatch

Elena Stepanova added a comment - 2019-07-27 23:26 Also, innodb.innodb-32k-crash test non-deterministically produces the same warning: http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos73-amd64/builds/11353/steps/mtr/logs/stdio 10.3 5e112a26201d4b343df3e401f8695974a8fa852c innodb.innodb-32k-crash 'innodb' w1 [ fail ] Test ended at 2019-07-27 13:16:40 CURRENT_TEST: innodb.innodb-32k-crash --- /usr/share/mysql-test/suite/innodb/r/innodb-32k-crash.result 2019-07-27 11:56:37.000000000 +0000 +++ /dev/shm/var/1/log/innodb-32k-crash.reject 2019-07-27 13:16:40.754215752 +0000 @@ -136,6 +136,8 @@ aa=@h,ba=@h,ca=@h,da=@h,ea=@h,fa=@h,ga=@h,ha=@h,ia=@h,ja=@h, ka=@h,la=@h,ma=@h,na=@h,oa=@h,pa=@h,qa=@h,ra=@h,sa=@h,ta=@b,ua=@h, va=@h,wa=@h,xa=@h,ya=@h,za=@h; +Warnings: +Warning 139 Row size too large (> 16318). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline. BEGIN; UPDATE t1 SET a=@g,b=@g,c=@g,d=@g,e=@g; UPDATE t1 SET f=@g,g=@g,h=@g,i=@g,j=@g; mysqltest: Result length mismatch

Geoff Montee (Inactive) made changes - 2019-08-16 00:03

Link

This issue relates to ~~MDEV-19292~~ [ ~~MDEV-19292~~ ]

Geoff Montee (Inactive) added a comment - 2019-08-20 19:07

2019-07-28  0:57:51 140189814937344 [Warning] InnoDB: Cannot add field `c08` in table `test`.`t1` because after adding it, the row size is 2484 which is greater than maximum allowed size (1982) for a record on index leaf page.

This warning would seem to imply that the c08 column is being added by some DDL statement, so it doesn't really make sense in the context of CHECK TABLE. I think this warning should be improved. See also MDEV-16969.

Geoff Montee (Inactive) added a comment - 2019-08-20 19:07 2019-07-28 0:57:51 140189814937344 [Warning] InnoDB: Cannot add field `c08` in table `test`.`t1` because after adding it, the row size is 2484 which is greater than maximum allowed size (1982) for a record on index leaf page. This warning would seem to imply that the c08 column is being added by some DDL statement, so it doesn't really make sense in the context of CHECK TABLE. I think this warning should be improved. See also MDEV-16969 .

Geoff Montee (Inactive) added a comment - 2019-08-20 19:13

This bug also affects mysql_upgrade, since that tool executes "CHECK TABLE ... FOR UPGRADE".

To reproduce with mysql_upgrade, do the following:

Create a table with a row size that is too large:

SET SESSION innodb_strict_mode=OFF;

CREATE TABLE test.tab (

   col1 varchar(40) NOT NULL,

   col2 varchar(40) NOT NULL,

   col3 varchar(40) NOT NULL,

   col4 varchar(40) NOT NULL,

   col5 varchar(40) NOT NULL,

   col6 varchar(40) NOT NULL,

   col7 varchar(40) NOT NULL,

   col8 varchar(40) NOT NULL,

   col9 varchar(40) NOT NULL,

   col10 varchar(40) NOT NULL,

   col11 varchar(40) NOT NULL,

   col12 varchar(40) NOT NULL,

   col13 varchar(40) NOT NULL,

   col14 varchar(40) NOT NULL,

   col15 varchar(40) NOT NULL,

   col16 varchar(40) NOT NULL,

   col17 varchar(40) NOT NULL,

   col18 varchar(40) NOT NULL,

   col19 varchar(40) NOT NULL,

   col20 varchar(40) NOT NULL,

   col21 varchar(40) NOT NULL,

   col22 varchar(40) NOT NULL,

   col23 varchar(40) NOT NULL,

   col24 varchar(40) NOT NULL,

   col25 varchar(40) NOT NULL,

   col26 varchar(40) NOT NULL,

   col27 varchar(40) NOT NULL,

   col28 varchar(40) NOT NULL,

   col29 varchar(40) NOT NULL,

   col30 varchar(40) NOT NULL,

   col31 varchar(40) NOT NULL,

   col32 varchar(40) NOT NULL,

   col33 varchar(40) NOT NULL,

   col34 varchar(40) NOT NULL,

   col35 varchar(40) NOT NULL,

   col36 varchar(40) NOT NULL,

   col37 varchar(40) NOT NULL,

   col38 varchar(40) NOT NULL,

   col39 varchar(40) NOT NULL,

   col40 varchar(40) NOT NULL,

   col41 varchar(40) NOT NULL,

   col42 varchar(40) NOT NULL,

   col43 varchar(40) NOT NULL,

   col44 varchar(40) NOT NULL,

   col45 varchar(40) NOT NULL,

   col46 varchar(40) NOT NULL,

   col47 varchar(40) NOT NULL,

   col48 varchar(40) NOT NULL,

   col49 varchar(40) NOT NULL,

   col50 varchar(40) NOT NULL,

   col51 varchar(40) NOT NULL,

   col52 varchar(40) NOT NULL,

   col53 varchar(40) NOT NULL,

   col54 varchar(40) NOT NULL,

   col55 varchar(40) NOT NULL,

   col56 varchar(40) NOT NULL,

   col57 varchar(40) NOT NULL,

   col58 varchar(40) NOT NULL,

   col59 varchar(40) NOT NULL,

   col60 varchar(40) NOT NULL,

   col61 varchar(40) NOT NULL,

   col62 varchar(40) NOT NULL,

   col63 varchar(40) NOT NULL,

   col64 varchar(40) NOT NULL,

   col65 varchar(40) NOT NULL,

   col66 varchar(40) NOT NULL,

   col67 varchar(40) NOT NULL,

   col68 varchar(40) NOT NULL,

   col69 varchar(40) NOT NULL,

   col70 varchar(40) NOT NULL,

   col71 varchar(40) NOT NULL,

   col72 varchar(40) NOT NULL,

   col73 varchar(40) NOT NULL,

   col74 varchar(40) NOT NULL,

   col75 varchar(40) NOT NULL,

   col76 varchar(40) NOT NULL,

   col77 varchar(40) NOT NULL,

   col78 varchar(40) NOT NULL,

   col79 varchar(40) NOT NULL,

   col80 varchar(40) NOT NULL,

   col81 varchar(40) NOT NULL,

   col82 varchar(40) NOT NULL,

   col83 varchar(40) NOT NULL,

   col84 varchar(40) NOT NULL,

   col85 varchar(40) NOT NULL,

   col86 varchar(40) NOT NULL,

   col87 varchar(40) NOT NULL,

   col88 varchar(40) NOT NULL,

   col89 varchar(40) NOT NULL,

   col90 varchar(40) NOT NULL,

   col91 varchar(40) NOT NULL,

   col92 varchar(40) NOT NULL,

   col93 varchar(40) NOT NULL,

   col94 varchar(40) NOT NULL,

   col95 varchar(40) NOT NULL,

   col96 varchar(40) NOT NULL,

   col97 varchar(40) NOT NULL,

   col98 varchar(40) NOT NULL,

   col99 varchar(40) NOT NULL,

   col100 varchar(40) NOT NULL,

   col101 varchar(40) NOT NULL,

   col102 varchar(40) NOT NULL,

   col103 varchar(40) NOT NULL,

   col104 varchar(40) NOT NULL,

   col105 varchar(40) NOT NULL,

   col106 varchar(40) NOT NULL,

   col107 varchar(40) NOT NULL,

   col108 varchar(40) NOT NULL,

   col109 varchar(40) NOT NULL,

   col110 varchar(40) NOT NULL,

   col111 varchar(40) NOT NULL,

   col112 varchar(40) NOT NULL,

   col113 varchar(40) NOT NULL,

   col114 varchar(40) NOT NULL,

   col115 varchar(40) NOT NULL,

   col116 varchar(40) NOT NULL,

   col117 varchar(40) NOT NULL,

   col118 varchar(40) NOT NULL,

   col119 varchar(40) NOT NULL,

   col120 varchar(40) NOT NULL,

   col121 varchar(40) NOT NULL,

   col122 varchar(40) NOT NULL,

   col123 varchar(40) NOT NULL,

   col124 varchar(40) NOT NULL,

   col125 varchar(40) NOT NULL,

   col126 varchar(40) NOT NULL,

   col127 varchar(40) NOT NULL,

   col128 varchar(40) NOT NULL,

   col129 varchar(40) NOT NULL,

   col130 varchar(40) NOT NULL,

   col131 varchar(40) NOT NULL,

   col132 varchar(40) NOT NULL,

   col133 varchar(40) NOT NULL,

   col134 varchar(40) NOT NULL,

   col135 varchar(40) NOT NULL,

   col136 varchar(40) NOT NULL,

   col137 varchar(40) NOT NULL,

   col138 varchar(40) NOT NULL,

   col139 varchar(40) NOT NULL,

   col140 varchar(40) NOT NULL,

   col141 varchar(40) NOT NULL,

   col142 varchar(40) NOT NULL,

   col143 varchar(40) NOT NULL,

   col144 varchar(40) NOT NULL,

   col145 varchar(40) NOT NULL,

   col146 varchar(40) NOT NULL,

   col147 varchar(40) NOT NULL,

   col148 varchar(40) NOT NULL,

   col149 varchar(40) NOT NULL,

   col150 varchar(40) NOT NULL,

   col151 varchar(40) NOT NULL,

   col152 varchar(40) NOT NULL,

   col153 varchar(40) NOT NULL,

   col154 varchar(40) NOT NULL,

   col155 varchar(40) NOT NULL,

   col156 varchar(40) NOT NULL,

   col157 varchar(40) NOT NULL,

   col158 varchar(40) NOT NULL,

   col159 varchar(40) NOT NULL,

   col160 varchar(40) NOT NULL,

   col161 varchar(40) NOT NULL,

   col162 varchar(40) NOT NULL,

   col163 varchar(40) NOT NULL,

   col164 varchar(40) NOT NULL,

   col165 varchar(40) NOT NULL,

   col166 varchar(40) NOT NULL,

   col167 varchar(40) NOT NULL,

   col168 varchar(40) NOT NULL,

   col169 varchar(40) NOT NULL,

   col170 varchar(40) NOT NULL,

   col171 varchar(40) NOT NULL,

   col172 varchar(40) NOT NULL,

   col173 varchar(40) NOT NULL,

   col174 varchar(40) NOT NULL,

   col175 varchar(40) NOT NULL,

   col176 varchar(40) NOT NULL,

   col177 varchar(40) NOT NULL,

   col178 varchar(40) NOT NULL,

   col179 varchar(40) NOT NULL,

   col180 varchar(40) NOT NULL,

   col181 varchar(40) NOT NULL,

   col182 varchar(40) NOT NULL,

   col183 varchar(40) NOT NULL,

   col184 varchar(40) NOT NULL,

   col185 varchar(40) NOT NULL,

   col186 varchar(40) NOT NULL,

   col187 varchar(40) NOT NULL,

   col188 varchar(40) NOT NULL,

   col189 varchar(40) NOT NULL,

   col190 varchar(40) NOT NULL,

   col191 varchar(40) NOT NULL,

   col192 varchar(40) NOT NULL,

   col193 varchar(40) NOT NULL,

   col194 varchar(40) NOT NULL,

   col195 varchar(40) NOT NULL,

   col196 varchar(40) NOT NULL,

   col197 varchar(40) NOT NULL,

   col198 varchar(40) NOT NULL,

   PRIMARY KEY (col1)

) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET=utf8;

Then, restart the server:

sudo systemctl restart mariadb

Then, before you do anything else with the database, run mysql_upgrade:

sudo mysql_upgrade

mysql_upgrade will finish successfully, and it won't report any errors. However, it will cause the misleading warning to be written to the MariaDB error log.

2019-08-20 19:11:45 22 [Warning] InnoDB: Cannot add field `col68` in table `test`.`tab` because after adding it, the row size is 8246 which is greater than maximum allowed size (8126) for a record on index leaf page.

Geoff Montee (Inactive) added a comment - 2019-08-20 19:13 This bug also affects mysql_upgrade, since that tool executes "CHECK TABLE ... FOR UPGRADE". To reproduce with mysql_upgrade, do the following: Create a table with a row size that is too large: SET SESSION innodb_strict_mode=OFF; CREATE TABLE test.tab ( col1 varchar(40) NOT NULL, col2 varchar(40) NOT NULL, col3 varchar(40) NOT NULL, col4 varchar(40) NOT NULL, col5 varchar(40) NOT NULL, col6 varchar(40) NOT NULL, col7 varchar(40) NOT NULL, col8 varchar(40) NOT NULL, col9 varchar(40) NOT NULL, col10 varchar(40) NOT NULL, col11 varchar(40) NOT NULL, col12 varchar(40) NOT NULL, col13 varchar(40) NOT NULL, col14 varchar(40) NOT NULL, col15 varchar(40) NOT NULL, col16 varchar(40) NOT NULL, col17 varchar(40) NOT NULL, col18 varchar(40) NOT NULL, col19 varchar(40) NOT NULL, col20 varchar(40) NOT NULL, col21 varchar(40) NOT NULL, col22 varchar(40) NOT NULL, col23 varchar(40) NOT NULL, col24 varchar(40) NOT NULL, col25 varchar(40) NOT NULL, col26 varchar(40) NOT NULL, col27 varchar(40) NOT NULL, col28 varchar(40) NOT NULL, col29 varchar(40) NOT NULL, col30 varchar(40) NOT NULL, col31 varchar(40) NOT NULL, col32 varchar(40) NOT NULL, col33 varchar(40) NOT NULL, col34 varchar(40) NOT NULL, col35 varchar(40) NOT NULL, col36 varchar(40) NOT NULL, col37 varchar(40) NOT NULL, col38 varchar(40) NOT NULL, col39 varchar(40) NOT NULL, col40 varchar(40) NOT NULL, col41 varchar(40) NOT NULL, col42 varchar(40) NOT NULL, col43 varchar(40) NOT NULL, col44 varchar(40) NOT NULL, col45 varchar(40) NOT NULL, col46 varchar(40) NOT NULL, col47 varchar(40) NOT NULL, col48 varchar(40) NOT NULL, col49 varchar(40) NOT NULL, col50 varchar(40) NOT NULL, col51 varchar(40) NOT NULL, col52 varchar(40) NOT NULL, col53 varchar(40) NOT NULL, col54 varchar(40) NOT NULL, col55 varchar(40) NOT NULL, col56 varchar(40) NOT NULL, col57 varchar(40) NOT NULL, col58 varchar(40) NOT NULL, col59 varchar(40) NOT NULL, col60 varchar(40) NOT NULL, col61 varchar(40) NOT NULL, col62 varchar(40) NOT NULL, col63 varchar(40) NOT NULL, col64 varchar(40) NOT NULL, col65 varchar(40) NOT NULL, col66 varchar(40) NOT NULL, col67 varchar(40) NOT NULL, col68 varchar(40) NOT NULL, col69 varchar(40) NOT NULL, col70 varchar(40) NOT NULL, col71 varchar(40) NOT NULL, col72 varchar(40) NOT NULL, col73 varchar(40) NOT NULL, col74 varchar(40) NOT NULL, col75 varchar(40) NOT NULL, col76 varchar(40) NOT NULL, col77 varchar(40) NOT NULL, col78 varchar(40) NOT NULL, col79 varchar(40) NOT NULL, col80 varchar(40) NOT NULL, col81 varchar(40) NOT NULL, col82 varchar(40) NOT NULL, col83 varchar(40) NOT NULL, col84 varchar(40) NOT NULL, col85 varchar(40) NOT NULL, col86 varchar(40) NOT NULL, col87 varchar(40) NOT NULL, col88 varchar(40) NOT NULL, col89 varchar(40) NOT NULL, col90 varchar(40) NOT NULL, col91 varchar(40) NOT NULL, col92 varchar(40) NOT NULL, col93 varchar(40) NOT NULL, col94 varchar(40) NOT NULL, col95 varchar(40) NOT NULL, col96 varchar(40) NOT NULL, col97 varchar(40) NOT NULL, col98 varchar(40) NOT NULL, col99 varchar(40) NOT NULL, col100 varchar(40) NOT NULL, col101 varchar(40) NOT NULL, col102 varchar(40) NOT NULL, col103 varchar(40) NOT NULL, col104 varchar(40) NOT NULL, col105 varchar(40) NOT NULL, col106 varchar(40) NOT NULL, col107 varchar(40) NOT NULL, col108 varchar(40) NOT NULL, col109 varchar(40) NOT NULL, col110 varchar(40) NOT NULL, col111 varchar(40) NOT NULL, col112 varchar(40) NOT NULL, col113 varchar(40) NOT NULL, col114 varchar(40) NOT NULL, col115 varchar(40) NOT NULL, col116 varchar(40) NOT NULL, col117 varchar(40) NOT NULL, col118 varchar(40) NOT NULL, col119 varchar(40) NOT NULL, col120 varchar(40) NOT NULL, col121 varchar(40) NOT NULL, col122 varchar(40) NOT NULL, col123 varchar(40) NOT NULL, col124 varchar(40) NOT NULL, col125 varchar(40) NOT NULL, col126 varchar(40) NOT NULL, col127 varchar(40) NOT NULL, col128 varchar(40) NOT NULL, col129 varchar(40) NOT NULL, col130 varchar(40) NOT NULL, col131 varchar(40) NOT NULL, col132 varchar(40) NOT NULL, col133 varchar(40) NOT NULL, col134 varchar(40) NOT NULL, col135 varchar(40) NOT NULL, col136 varchar(40) NOT NULL, col137 varchar(40) NOT NULL, col138 varchar(40) NOT NULL, col139 varchar(40) NOT NULL, col140 varchar(40) NOT NULL, col141 varchar(40) NOT NULL, col142 varchar(40) NOT NULL, col143 varchar(40) NOT NULL, col144 varchar(40) NOT NULL, col145 varchar(40) NOT NULL, col146 varchar(40) NOT NULL, col147 varchar(40) NOT NULL, col148 varchar(40) NOT NULL, col149 varchar(40) NOT NULL, col150 varchar(40) NOT NULL, col151 varchar(40) NOT NULL, col152 varchar(40) NOT NULL, col153 varchar(40) NOT NULL, col154 varchar(40) NOT NULL, col155 varchar(40) NOT NULL, col156 varchar(40) NOT NULL, col157 varchar(40) NOT NULL, col158 varchar(40) NOT NULL, col159 varchar(40) NOT NULL, col160 varchar(40) NOT NULL, col161 varchar(40) NOT NULL, col162 varchar(40) NOT NULL, col163 varchar(40) NOT NULL, col164 varchar(40) NOT NULL, col165 varchar(40) NOT NULL, col166 varchar(40) NOT NULL, col167 varchar(40) NOT NULL, col168 varchar(40) NOT NULL, col169 varchar(40) NOT NULL, col170 varchar(40) NOT NULL, col171 varchar(40) NOT NULL, col172 varchar(40) NOT NULL, col173 varchar(40) NOT NULL, col174 varchar(40) NOT NULL, col175 varchar(40) NOT NULL, col176 varchar(40) NOT NULL, col177 varchar(40) NOT NULL, col178 varchar(40) NOT NULL, col179 varchar(40) NOT NULL, col180 varchar(40) NOT NULL, col181 varchar(40) NOT NULL, col182 varchar(40) NOT NULL, col183 varchar(40) NOT NULL, col184 varchar(40) NOT NULL, col185 varchar(40) NOT NULL, col186 varchar(40) NOT NULL, col187 varchar(40) NOT NULL, col188 varchar(40) NOT NULL, col189 varchar(40) NOT NULL, col190 varchar(40) NOT NULL, col191 varchar(40) NOT NULL, col192 varchar(40) NOT NULL, col193 varchar(40) NOT NULL, col194 varchar(40) NOT NULL, col195 varchar(40) NOT NULL, col196 varchar(40) NOT NULL, col197 varchar(40) NOT NULL, col198 varchar(40) NOT NULL, PRIMARY KEY (col1) ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET=utf8; Then, restart the server: sudo systemctl restart mariadb Then, before you do anything else with the database, run mysql_upgrade: sudo mysql_upgrade mysql_upgrade will finish successfully, and it won't report any errors. However, it will cause the misleading warning to be written to the MariaDB error log. 2019-08-20 19:11:45 22 [Warning] InnoDB: Cannot add field `col68` in table `test`.`tab` because after adding it, the row size is 8246 which is greater than maximum allowed size (8126) for a record on index leaf page.

Geoff Montee (Inactive) made changes - 2019-08-20 19:16

Link

This issue relates to MDEV-16969 [ MDEV-16969 ]

Marko Mäkelä added a comment - 2019-08-21 06:58

kevg, I think that such messages should only be issued to the client connection when executing DDL statements. If we are loading an ‘unsafe’ table definition to the data dictionary cache, we should be silent. If the row size is too large, that should then result in an error on an INSERT or UPDATE operation.

Side note: The FOR UPGRADE clause of CHECK TABLE is being ignored by InnoDB.

Marko Mäkelä added a comment - 2019-08-21 06:58 kevg , I think that such messages should only be issued to the client connection when executing DDL statements. If we are loading an ‘unsafe’ table definition to the data dictionary cache, we should be silent. If the row size is too large, that should then result in an error on an INSERT or UPDATE operation. Side note: The FOR UPGRADE clause of CHECK TABLE is being ignored by InnoDB.

Geoff Montee (Inactive) made changes - 2019-08-21 22:48

Link

This issue relates to MDEV-20400 [ MDEV-20400 ]

Eugene Kosov (Inactive) made changes - 2019-08-27 11:13

Status

Open [ 1 ]

In Progress [ 3 ]

Eugene Kosov (Inactive) made changes - 2019-08-29 10:08

Assignee	Eugene Kosov [ kevg ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Eugene Kosov (Inactive) made changes - 2019-09-05 09:45

Assignee

Marko Mäkelä [ marko ]

Eugene Kosov [ kevg ]

Eugene Kosov (Inactive) made changes - 2019-09-10 14:47

Status

In Review [ 10002 ]

Stalled [ 10000 ]

Eugene Kosov (Inactive) made changes - 2019-09-10 14:47

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Eugene Kosov (Inactive) made changes - 2019-09-16 09:31

Assignee	Eugene Kosov [ kevg ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä added a comment - 2019-09-20 12:15

The big picture looks good.

I think that I found some inaccuracy in the calculation of the maximum node pointer record size. You do not seem to be accounting for the 4-byte child page number field.

For the clustered index node pointer records, the node pointer size should never cause problems. This is because the node pointer records will be (primary_key_columns,child_page_number), while the leaf page records are (primary_key_columns,DB_TRX_ID,DB_ROLL_PTR,any_non_pk_columns). The system columns DB_TRX_ID,DB_ROLL_PTR are 13 bytes, while the child_page_number is only 4 bytes.

So, we should enforce the maximum node pointer record size only for secondary indexes. Note that for SPATIAL INDEX, the maximum node pointer record size can never become a problem. I think that the node pointer is DATA_MBR_LEN (4*sizeof(double)) followed by the child page number (no PRIMARY KEY columns, but you’d better check that). The leaf page records are DATA_MBR_LEN followed by the PRIMARY KEY columns. That might theoretically become a bottleneck with a 16-column PRIMARY KEY consisting of very long maximum values, if all columns of the table belong to the PRIMARY KEY.

Marko Mäkelä added a comment - 2019-09-20 12:15 The big picture looks good. I think that I found some inaccuracy in the calculation of the maximum node pointer record size. You do not seem to be accounting for the 4-byte child page number field. For the clustered index node pointer records, the node pointer size should never cause problems. This is because the node pointer records will be (primary_key_columns,child_page_number), while the leaf page records are (primary_key_columns,DB_TRX_ID,DB_ROLL_PTR,any_non_pk_columns). The system columns DB_TRX_ID,DB_ROLL_PTR are 13 bytes, while the child_page_number is only 4 bytes. So, we should enforce the maximum node pointer record size only for secondary indexes. Note that for SPATIAL INDEX , the maximum node pointer record size can never become a problem. I think that the node pointer is DATA_MBR_LEN ( 4*sizeof(double) ) followed by the child page number (no PRIMARY KEY columns, but you’d better check that). The leaf page records are DATA_MBR_LEN followed by the PRIMARY KEY columns. That might theoretically become a bottleneck with a 16-column PRIMARY KEY consisting of very long maximum values, if all columns of the table belong to the PRIMARY KEY .

Marko Mäkelä made changes - 2019-09-20 12:15

Assignee	Marko Mäkelä [ marko ]	Eugene Kosov [ kevg ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Hartmut Holzgraefe added a comment - 2019-10-14 19:54

"If we are loading an ‘unsafe’ table definition to the data dictionary cache, we should be silent."

This is also an issue as the error log can be flooded with such messages, especially after startup when the table_definition_cache is still "cold". This can become especially "interesting" when having heavily partition tables, where the warning is logged for each individual partition.

Should we keep this aspect as part of this ticked, or should we actually split this aspect out into a new MDEV of its own?

Hartmut Holzgraefe added a comment - 2019-10-14 19:54 "If we are loading an ‘unsafe’ table definition to the data dictionary cache, we should be silent." This is also an issue as the error log can be flooded with such messages, especially after startup when the table_definition_cache is still "cold". This can become especially "interesting" when having heavily partition tables, where the warning is logged for each individual partition. Should we keep this aspect as part of this ticked, or should we actually split this aspect out into a new MDEV of its own?

Geoff Montee (Inactive) made changes - 2019-10-15 08:18

Link

This issue relates to ~~MDEV-20832~~ [ ~~MDEV-20832~~ ]

Alice Sherepa made changes - 2019-10-15 12:29

Link

This issue relates to ~~MDEV-20786~~ [ ~~MDEV-20786~~ ]

Alice Sherepa made changes - 2019-10-15 12:30

Link

This issue relates to ~~MDEV-20786~~ [ ~~MDEV-20786~~ ]

Geoff Montee (Inactive) made changes - 2019-10-15 17:59

Link

This issue relates to ~~MDEV-20786~~ [ ~~MDEV-20786~~ ]

Hartmut Holzgraefe added a comment - 2019-10-22 14:41

Also if we decide to continue having these warnings in the error log, could we at least only have them logged if innodb_strict_mode=ON?

Hartmut Holzgraefe added a comment - 2019-10-22 14:41 Also if we decide to continue having these warnings in the error log, could we at least only have them logged if innodb_strict_mode=ON?

Geoff Montee (Inactive) added a comment - 2019-10-22 14:46

Also if we decide to continue having these warnings in the error log, could we at least only have them logged if innodb_strict_mode=ON?

Another option is that if innodb_strict_mode=OFF is set, then the logging behavior can be based on log_warnings, as requested in ~~MDEV-20832~~.

Geoff Montee (Inactive) added a comment - 2019-10-22 14:46 Also if we decide to continue having these warnings in the error log, could we at least only have them logged if innodb_strict_mode=ON? Another option is that if innodb_strict_mode =OFF is set, then the logging behavior can be based on log_warnings , as requested in MDEV-20832 .

Geoff Montee (Inactive) made changes - 2019-10-23 13:14

Link

This issue relates to MENT-443 [ MENT-443 ]

Julien Fritsch made changes - 2019-10-31 14:16

Link

This issue duplicates MENT-454 [ MENT-454 ]

Eugene Kosov (Inactive) made changes - 2019-11-02 21:13

Link

This issue includes ~~MDEV-20949~~ [ ~~MDEV-20949~~ ]

Julien Fritsch made changes - 2019-11-12 20:31

Priority

Major [ 3 ]

Critical [ 2 ]

Marko Mäkelä added a comment - 2019-11-14 12:03

Some of my comments related to the ~~MDEV-20949~~ fix should be helpful for fixing this.

Marko Mäkelä added a comment - 2019-11-14 12:03 Some of my comments related to the MDEV-20949 fix should be helpful for fixing this.

Geoff Montee (Inactive) made changes - 2019-11-19 19:13

Link

This issue relates to MENT-514 [ MENT-514 ]

Marko Mäkelä made changes - 2019-11-27 11:47

Labels

affects-tests

Geoff Montee (Inactive) made changes - 2019-12-09 18:49

Link

This issue relates to MDEV-21261 [ MDEV-21261 ]

Geoff Montee (Inactive) made changes - 2020-01-07 19:36

Link

This issue relates to ~~MDEV-21429~~ [ ~~MDEV-21429~~ ]

Julien Fritsch made changes - 2020-01-26 11:58

Priority

Critical [ 2 ]

Major [ 3 ]

Marko Mäkelä made changes - 2020-02-01 07:08

Link

This issue relates to ~~MDEV-21624~~ [ ~~MDEV-21624~~ ]

Marko Mäkelä made changes - 2020-03-10 08:09

Link

This issue relates to ~~MDEV-21748~~ [ ~~MDEV-21748~~ ]

Marko Mäkelä added a comment - 2020-03-10 08:09

As demonstrated in ~~MDEV-21748~~, in MariaDB 10.3 the function instant_alter_column_possible() is computing max_size in the wrong way, not taking blob_prefix correctly into account. This will unnecessarily prevent instant ADD COLUMN operations.

Marko Mäkelä added a comment - 2020-03-10 08:09 As demonstrated in MDEV-21748 , in MariaDB 10.3 the function instant_alter_column_possible() is computing max_size in the wrong way, not taking blob_prefix correctly into account. This will unnecessarily prevent instant ADD COLUMN operations.

Julien Fritsch made changes - 2020-03-16 10:21

Priority

Major [ 3 ]

Critical [ 2 ]

Geoff Montee (Inactive) made changes - 2020-05-16 00:15

Link

This issue relates to MDEV-22585 [ MDEV-22585 ]

Marko Mäkelä made changes - 2020-08-05 12:31

Link

This issue relates to MDEV-20400 [ MDEV-20400 ]

Ralf Gebhardt made changes - 2020-09-18 11:10

Link

This issue blocks MDEV-20400 [ MDEV-20400 ]

Ralf Gebhardt made changes - 2021-02-26 14:17

Link

This issue blocks MENT-1125 [ MENT-1125 ]

Sergei Golubchik made changes - 2021-12-06 21:35

Workflow

MariaDB v3 [ 98560 ]

MariaDB v4 [ 143604 ]

Marko Mäkelä made changes - 2022-02-21 14:19

Assignee

Eugene Kosov [ kevg ]

Thirunarayanan Balathandayuthapani [ thiru ]

Marko Mäkelä made changes - 2022-02-21 14:33

Link

This issue relates to MDEV-20000 [ MDEV-20000 ]

Thirunarayanan Balathandayuthapani made changes - 2022-04-12 12:06

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Thirunarayanan Balathandayuthapani added a comment - 2022-04-13 14:26

Patch is in bb-10.3-MDEV-20194

Thirunarayanan Balathandayuthapani added a comment - 2022-04-13 14:26 Patch is in bb-10.3- MDEV-20194

Thirunarayanan Balathandayuthapani made changes - 2022-04-13 14:26

Status

In Progress [ 3 ]

In Review [ 10002 ]

Thirunarayanan Balathandayuthapani made changes - 2022-04-18 05:03

Assignee

Thirunarayanan Balathandayuthapani [ thiru ]

Marko Mäkelä [ marko ]

Marko Mäkelä added a comment - 2022-04-20 07:37

Thank you. I spotted a possible off-by-one error for ROW_FORMAT=REDUNDANT node pointer records. Otherwise, it looks OK to me.

Marko Mäkelä added a comment - 2022-04-20 07:37 Thank you. I spotted a possible off-by-one error for ROW_FORMAT=REDUNDANT node pointer records. Otherwise, it looks OK to me.

Marko Mäkelä made changes - 2022-04-20 07:37

Assignee	Marko Mäkelä [ marko ]	Thirunarayanan Balathandayuthapani [ thiru ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Thirunarayanan Balathandayuthapani made changes - 2022-04-21 00:29

Fix Version/s		10.3.35 [ 27512 ]
Fix Version/s		10.4.25 [ 27510 ]
Fix Version/s		10.5.16 [ 27508 ]
Fix Version/s		10.6.8 [ 27506 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Jira Automation (IT) made changes - 2024-07-04 03:50

Zendesk Related Tickets

147879 113644 118409 185863 160501 150204 114072 195104 198426 164062 166795 159353

People

Assignee:: Thirunarayanan Balathandayuthapani

Reporter:: Elena Stepanova

Votes:: 2 Vote for this issue

Watchers:: 8 Start watching this issue

Dates

Created:: 2019-07-27 22:04

Updated:: 2024-07-07 22:47

Resolved:: 2022-04-21 00:29

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration