[debian-mysql] Bug#920608: Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'

[Marko Mäkelä]

Hi Olaf,

> > The parameters innodb_large_prefix and innodb_file_format were
> > deprecated in MySQL 5.7 and MariaDB 10.2, and removed in MySQL 8.0 and
> > MariaDB 10.3.
>
> What's the deprecation policy?
> I think the time between deprecation and removal is too short.

For Oracle, the policy is to deprecate in an earlier version (possibly
in an update to a GA release) and to remove in the next major version
(which is not yet released as GA).

> > How long should obscure parameters be preserved?
>
> Were large-prefix and file-format obscure? They were in the debian
> default maria db conf files..

They should have been made default and deprecated way before version
5.7. The only reason for the parameters to exist was to theoretically
allow downgrading to MySQL 5.1. I do not think that such downgrading
was ever tested.

> How long? Ideally until major distros have all shipped a MariaDB
> version with the deprecation warnings.

That is a good point.

> Treating unknown settings as warnings rather then errors would work too.

I think that this is too risky. We do want to catch typos.

> > Forever? What about
> > old syntax? The following worked in MySQL 5.0, but no longer in MySQL
> > 5.1 or MariaDB:
> > create table t(a int) type=innodb;
>
> Syntax is different, when did engine= become available?

TYPE=InnoDB (or other storage engines) was deprecated in MySQL 4.1.2,
in the same commit that introduced ENGINE=InnoDB syntax.
So, at that time, the time frame from deprecation to removal was 2
major releases.

The following were removed from InnoDB in MariaDB 10.3:
innodb_support_xa
innodb_use_mtflush, innodb_mtflush_threads
innodb_file_format
innodb_file_format_check
innodb_file_format_max
innodb_large_prefix
innodb_instrument_semaphores
innodb_use_fallocate

Which removed parameters would you want to be recognized?

Note: Many parameters are listed in removed_variables[] in
sql/upgrade_conf_file.cc, used for building the mysql_upgrade_service
executable.
-- 
Marko Mäkelä, Lead Developer InnoDB
MariaDB Corporation