[MDEV-19016] Table in InnoDB data dictionary contains invalid flags upon undo-upgrade from 10.1.8 Created: 2019-03-21 Updated: 2019-03-22 Resolved: 2019-03-22 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Storage Engine - XtraDB |
| Affects Version/s: | 10.2, 10.3, 10.4 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Marko Mäkelä |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
mysql_upgrade fails saying that tables don't exist in the engine. Possibly such upgrade from 10.1.8 is not supported (as it was a fairly broken version), but then maybe InnoDB could just say so and refuse to start? To reproduce:
|
| Comments |
| Comment by Marko Mäkelä [ 2019-03-22 ] | ||||||||||
|
The SYS_TABLES.N_COLS value 2147483660 is 1<<31|8, meaning that the ROW_FORMAT is not REDUNDANT, and the number of user-defined stored columns is 8. There was a problem related to SYS_TABLES.TYPE in MariaDB between versions 10.2.2 and 10.2.6, which was fixed in
The reason why these are invalid is that ROW_FORMAT=COMPRESSED only supports innodb_page_size up to 16k, but the dataset uses innodb_page_size=32k. In ROW_FORMAT=COMPRESSED, the page directory at the end of the compressed page reserves the 2 most significant bits of the 16-bit byte offsets for flags, hence limiting innodb_page_size to at most 16k. The creation of invalid ROW_FORMAT=COMPRESSED tables was prevented in MariaDB 10.1.9 as part of fixing Note: there were other corruption bugs related to the larger page sizes. Examples include | ||||||||||
| Comment by Marko Mäkelä [ 2019-03-22 ] | ||||||||||
|
This is a GIGO (garbage in, garbage out) situation. I would say that such unconstrained upgrade testing is not feasible before 10.1.9, and with innodb_page_size=64k not before 10.1.26 or 10.2.8. |