Debian Unstable, Debian Testing and Debian Stable

This is the related bugreport in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886756

Any news on that? @dr-m, do you think that a fix will make it into the next mariadb 10.1 release?

Any news on that? @dr-m, do you think that a fix will make it into the next mariadb 10.1 release?

mejo, sorry, I was busy with the 10.3.5 RC and the https://m18.mariadb.com preparations.
I just started working on this, and will submit a patch for review today.

As part of this, the parameter innodb_file_format (which was deprecated in MySQL 5.7 and MariaDB 10.2) will lose its meaning: tables can be created in ROW_FORMAT=DYNAMIC despite what this setting says.

For maximum compatibility with older versions, the default value of the new parameter would be innodb_default_row_format=compact. In MariaDB 10.2, the default is dynamic.

bb-10.1-marko

Thanks a lot for the backport, @marko! Is there any ETA for the release of 10.1.32?

mejo, the next 10.1 release should be in about 3 weeks. I would appreciate it if you can test if a package of the newest 10.1 build works for you and provide feedback. Remember to set the following:

innodb_large_prefix=on

innodb_default_row_format=dynamic

I'm running a 3rd party application on Debian 9, I have upgraded MariaDB to 10.1.35 and added the properties in /etc/mysql/mariadb.conf.d/50-server.cnf:

innodb_file_format = Barracuda
innodb_file_per_table = On
innodb_large_prefix = On
innodb_default_row_format = dynamic

but it still fails for "Specified key was too long; max key length is 767 bytes". Because I don't know what the application is doing, is there a simple way for me to verify I have upgraded MariaDB and configured correctly? Thanks in advance!

Dagang Wei, if the application is doing CREATE INDEX or ALTER TABLE…ADD INDEX on an existing table, then the ROW_FORMAT of that table would be preserved. If the ROW_FORMAT is REDUNDANT (the old format before MySQL 5.0.3) or COMPACT (the default since MySQL 5.0.3), the limits would apply.

You could try rebuilding all tables (ALTER TABLE … ROW_FORMAT=DYNAMIC), or initialize the database from an SQL dump (after ensuring that there are no ROW_FORMAT attributes referring to old formats).

Dagang Wei, if the application is doing CREATE INDEX or ALTER TABLE…ADD INDEX on an existing table, then the ROW_FORMAT of that table would be preserved. If the ROW_FORMAT is REDUNDANT (the old format before MySQL 5.0.3) or COMPACT (the default since MySQL 5.0.3), the limits would apply.

You could try rebuilding all tables (ALTER TABLE … ROW_FORMAT=DYNAMIC), or initialize the database from an SQL dump (after ensuring that there are no ROW_FORMAT attributes referring to old formats).

Note that any ROW_FORMAT returned by SHOW CREATE TABLE will only show what was specified at CREATE TABLE time. Based on InnoDB parameters, InnoDB could choose a different format. SHOW TABLE STATUS should display the format chosen by InnoDB.