On 07/03/2017 04:00, Marco Nicosia wrote:
We noticed a change between MariaDB 10.1.18 and 10.1.20, but I haven't been able to find anything in the changelogs or JIRA that would help me understand what changed, and why.
On 10.1.18, if I set `innodb_large_prefix=OFF` I can create indexes with lengths greater than 767 bytes and MariaDB only issues a warning. If I configure `innodb_large_prefix=ON` I get an error and the index fails to create. This seems like a bug?
On 10.1.20, mysql fails to create the index regardless of how innodb_large_prefix is configured.
We think that the result is that in 10.1.20, 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.
Is this the desired behavior? Was there a bug in 10.1.18 (and maybe previous)?
I'm trying to understand the context better so that when devs ask us why index creation is failing, we give them the correct answer for why it used to work, and what they should be doing differently now that we're on 10.1.20.
I wonder if it's related to this commit, from 10.1.19: https://github.com/MariaDB/server/commit/d451d77 I can't recreate the behaviour you mention from 10.1.18, but yes, it does seems like a bug, as the only way I'm aware of that indexes greater than 767 can be created is with innodb_large_prefix and its related requirements. Can you share your settings/statements that permitted this?