maria-developers team mailing list archive

[Marko Mäkelä <marko.makela@xxxxxxxxxxx>]

Hi Sergei,

On Thu, Feb 28, 2019 at 5:08 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
>
> Hi, Marko!
>
> On Feb 27, Marko Mäkelä wrote:
> > Greetings from MariaDB Openworks in New York City.
> >
> > I just discussed this with Monty. His idea is that "don’t care"
> > attributes should be ignored, or at most a warning could be issued for
> > them. This allows ALTER TABLE from one storage engine to another while
> > preserving attributes that only matter for some storage engines.
>
> This behavior is configurable. We've got many complaints about this
> "ignored" behavior. Currently unknown (not "invalid values" - only
> completely unknown) attributes are ignored only if
> IGNORE_BAD_TABLE_OPTIONS sql-mode is enabled.
>
> > Based on that basic principle, we should ignore the encryption_key_id
> > attribute (whether or not it was explicitly specified by the user, or
> > inherited from the session variable innodb_default_encryption_key_id).
>
> encryption_key_id is not "don't care", it's something that a user
> expects to be used after innodb_encrypt_tables=ON. This was the whole
> reason of MDEV-17230 in the first place.
>
> Do you suggest to un-fix MDEV-17230 and ignore the user specified
> encryption key id unless it can be used used right away? It's possible,
> and it'll fix MDEV-18601.

I believe that our best option is to basically turn into a warning the
error that was introduced in MDEV-17230.

I did that and some other cleanup in my proposed patch at
https://github.com/MariaDB/server/commit/e39d6e0c53bccaf0c6b2a0341f8deb420f5e79be
which I plan to push to 10.1 if it passes the tests.

In MariaDB Server 10.2 or later versions we would be able to actually
fix the root cause of what was reported in MDEV-17230, by opening the
.frm file from within InnoDB when encryption is about to be enabled.

If you have something against this plan, please let me know.

Marko