[MDEV-12210] innodb_large_prefix disabled no longer allows large index creation Created: 2017-03-09 Updated: 2017-05-01 Resolved: 2017-05-01 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.1.20 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Marco N | Assignee: | Unassigned |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| 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: What is the correct thing for us to do, given this change? |
| Comments |
| Comment by Elena Stepanova [ 2017-03-12 ] |
|
Could you please provide an example which shows different behavior between 10.1.18 and 10.1.20? Please also attach your cnf file(s). |
| Comment by Elena Stepanova [ 2017-04-19 ] |
|
Closing due to inactivity. |
| Comment by Marco N [ 2017-04-26 ] |
|
We figured out that this was not a bug nor a regression - it's because simultaneous to upgrading to 10.1.20, we also added STRICT_ALL_TABLES to sql_mode. We had made the changes so far apart that we'd totally forgotten about the addition to sql_mode. Sorry for the false report! |