summaryrefslogtreecommitdiff
path: root/BUILD/compile-ppc-debug-max
diff options
context:
space:
mode:
authorMarko Mäkelä <marko.makela@mariadb.com>2022-04-29 12:32:44 +0300
committerMarko Mäkelä <marko.makela@mariadb.com>2022-04-29 12:32:44 +0300
commit8c1c61309d0a9d8da0ad51326f3fb1f1f7922bf6 (patch)
treecd7991bb0e4ba3c69ae274edc3b607c6e7783a9a /BUILD/compile-ppc-debug-max
parent03e703fd74b43ffd27e858e03e9d147029de086e (diff)
downloadmariadb-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