diff options
author | Marko Mäkelä <marko.makela@mariadb.com> | 2022-04-29 12:32:44 +0300 |
---|---|---|
committer | Marko Mäkelä <marko.makela@mariadb.com> | 2022-04-29 12:32:44 +0300 |
commit | 8c1c61309d0a9d8da0ad51326f3fb1f1f7922bf6 (patch) | |
tree | cd7991bb0e4ba3c69ae274edc3b607c6e7783a9a /BUILD/compile-ppc-debug-max | |
parent | 03e703fd74b43ffd27e858e03e9d147029de086e (diff) | |
download | mariadb-git-8c1c61309d0a9d8da0ad51326f3fb1f1f7922bf6.tar.gz |
MDEV-27274: DROP TABLE does not delete detached InnoDB files
In commit 1bd681c8b3c5213ce1f7976940a7dc38b48a0d39 (MDEV-25506 part 3)
the way how DDL transactions delete files was rewritten.
Only files that are actually attached to InnoDB tablespaces would be
deleted, and only after the DDL transaction was durably committed.
After a failed ALTER TABLE...IMPORT TABLESPACE, any data files that
the user might have moved to the data directory will not be attached
to the InnoDB data dictionary. Therefore, DROP TABLE would not
attempt to delete those files, and a subsequent CREATE TABLE would
fail. The logic was that the user who created the files outside the
DBMS is still the owner of those files, and InnoDB should not delete
those files because an "ownership transfer" (IMPORT TABLESPACE) was
not successfully completed.
However, not deleting those detached files could surprise users.
ha_innobase::delete_table(): Even if no tablespace exists, try to
delete any files that might match the table name.
Reviewed by: Thirunarayanan Balathandayuthapani
Diffstat (limited to 'BUILD/compile-ppc-debug-max')
0 files changed, 0 insertions, 0 deletions