Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
-
None
Description
Since there is no obviously "right" behavior in cases like this, I won't object if it gets downgraded after the initial analysis. In my opinion the biggest problem here is that errors like ER_NO_SUCH_TABLE_IN_ENGINE make impression of data corruption.
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (a INT, KEY (a)) ENGINE=InnoDB; |
CREATE TABLE t2 (b INT, FOREIGN KEY (b) REFERENCES t1 (a)) ENGINE=InnoDB; |
|
SET STATEMENT FOREIGN_KEY_CHECKS=OFF FOR ALTER TABLE t1 MODIFY a VARCHAR(8); |
|
--error ER_CANT_CREATE_TABLE
|
CREATE OR REPLACE TABLE t1 (c INT) ENGINE=InnoDB; |
SHOW CREATE TABLE t1; |
|
# Cleanup
|
DROP TABLE t2, t1; |
bb-10.11-midenok 8e82c973eeb |
query 'SHOW CREATE TABLE t1' failed: ER_NO_SUCH_TABLE_IN_ENGINE (1932): Table 'test.t1' doesn't exist in engine
|
Both pre-MDEV-25292 and the current 10.11 behave differently (older versions just drop t1 completely, and 10.11 pretends it gets re-created), so apparently this is already an effect of fixes pushed into bb-10.11-midenok.
Attachments
Issue Links
- is caused by
-
MDEV-25292 Atomic CREATE OR REPLACE TABLE
- Stalled
- relates to
-
MDEV-29701 Inconsistencies and eventual failure upon CREATE OR REPLACE with foreign keys
- Closed
-
MDEV-29779 Unexpected ER_ERROR_ON_RENAME upon CREATE OR REPLACE
- Closed