summaryrefslogtreecommitdiff
path: root/sql/sql_cmd.h
diff options
context:
space:
mode:
authorMarko Mäkelä <marko.makela@mariadb.com>2019-02-28 23:11:15 +0200
committerMarko Mäkelä <marko.makela@mariadb.com>2019-02-28 23:20:31 +0200
commite39d6e0c53bccaf0c6b2a0341f8deb420f5e79be (patch)
treea9b1664661e3164f80b8f1d2737751684b7c2aef /sql/sql_cmd.h
parent622e9e8a7a5e9babe1dd41e7499c20f396b6ebdf (diff)
downloadmariadb-git-e39d6e0c53bccaf0c6b2a0341f8deb420f5e79be.tar.gz
MDEV-18601 Can't create table with ENCRYPTED=DEFAULT when innodb_default_encryption_key_id!=1
The problem with the InnoDB table attribute encryption_key_id is that it is not being persisted anywhere in InnoDB except if the table attribute encryption is specified and is something else than encryption=default. MDEV-17320 made it a hard error if encryption_key_id is specified to be anything else than 1 in that case. Ideally, we would always persist encryption_key_id in InnoDB. But, then we would have to be prepared for the case that when encryption is being enabled for a table whose encryption_key_id attribute refers to a non-existing key. In MariaDB Server 10.1, our best option remains to not store anything inside InnoDB. But, instead of returning the error that MDEV-17320 introduced, we should merely issue a warning that the specified encryption_key_id is going to be ignored if encryption=default. To improve the situation a little more, we will issue a warning if SET [GLOBAL|SESSION] innodb_default_encryption_key_id is being set to something that does not refer to an available encryption key. Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the table definition from InnoDB side when the encryption is being enabled, and actually fix the root cause of what was reported in MDEV-17320.
Diffstat (limited to 'sql/sql_cmd.h')
0 files changed, 0 insertions, 0 deletions