maria-discuss team mailing list archive

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

On Mon, Sep 16, 2019 at 5:48 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
> Am 16.09.19 um 16:43 schrieb Marko Mäkelä:
> > Ultimately, for new DDL statements, this should be fixed when
> > MDEV-17567 implements Atomic DDL. I do not think that we can even then
> > safely remove #sql2 tables from old installations, because we must
> > think of upgrade scenarios.
>
> that all don't justify why the drop table simply can't remove the
> reference to something that literally don#t exist for a whole decade
>
> either that idiotic table is known or it's unknown

Like I wrote, we have to think of upgrade scenarios.

Specifically, we must keep in mind that before MDEV-14717 (in MariaDB
Server 10.3 and 10.2.19+), the InnoDB-internal RENAME operations were
not crash-safe at all. So, even if the InnoDB data dictionary thinks
that the table name should start with #sql2, it is perfectly possible
that the data file is known to the file system as something else. The
file is not necessarily entirely missing. And we cannot afford to read
the first page of each data file at startup, to find such orphan
files. That is simply too slow. In fact, I removed such code (which I
believed to be unnecessary) in 10.2.24 and 10.3.15: MDEV-18733 MariaDB
slow start after crash recovery

> if it's unknow get rid of it or at least allow the admin to do so with
> doing some crazy dance introducing way more room for troubles than just
> forget about something which isn't there anyways

You are welcome to submit a well designed, implemented and tested
patch to address this.
-- 
Marko Mäkelä, Lead Developer InnoDB
MariaDB Corporation