Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.1.20
-
None
Description
In 10.1.18, we observe a different behavior when `innodb_large_prefix=ON` than we see in 10.1.20.
On 10.1.18, if I set innodb_large_prefix=OFF I can create indexes with lengths greater than 767 bytes and mysql only issues a warning. If I configure innodb_large_prefix=ON I get an error and the index fails to create.
This seems like the correct behavior, as described here: https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_large_prefix
On 10.1.20, mysql fails to create the index regardless of how innodb_large_prefix is configured. Tables must be created or altered to use ROW_FORMAT DYNAMIC or ROW_FORMAT COMPRESSED if they are to contain an index with greater than 767 bytes in it.
This seems nice, in that allowing large keys to be truncated seems like a bad thing. But the way this has been implemented, it is not backward compatible - apps will fail, and apps that don't notice the failure will be in even worse shape than before.
Additionally, it seems that the administrator cannot do anything on the 10.1 series to enable that compatibility - it looks like the ability to specify a default is scheduled only for 10.2.2: MDEV-9646
What is the correct thing for us to do, given this change?
Attachments
Issue Links
- relates to
-
MDEV-9646 Allow setting default ROW_FORMAT (innodb_default_row_format)
- Closed
- links to