maria-discuss team mailing list archive

[Ian Gilfillan <ian@xxxxxxxxxxx>]

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?