Details
-
Type:
Task
-
Status: In Progress (View Workflow)
-
Priority:
Critical
-
Resolution: Unresolved
-
Fix Version/s: 10.11
-
Component/s: Data Definition - Create Table
-
Labels:None
Description
Atomic drop table (MDEV-23844) does not recover the replaced table if CREATE OR REPLACE TABLE fails.
This is because current, as before, CREATE OR REPLACE TABLE foo ... is implemented as:
DROP TABLE IF EXISTS foo;
CREATE TABLE foo ..
Because of that failed CREATE OR REPLACE TABLE or a crash during the create will lead to lost table, if the original table existed.
This task equips table drop with backing up the old table until the new table was successfully created.
In other words, this task ensures that if one executes CREATE OR REPLACE TABLE foo on an existing table, the table foo will either be the new or old table after the statement has executed, including in the cases the CREATE fails or the server crashes.
Attachments
Issue Links
- blocks
-
MDEV-27180 Fully atomic partitioning DDL operations
-
- In Review
-
- causes
-
MDEV-28933 CREATE OR REPLACE fails to recreate same constraint name
-
- In Review
-
-
MDEV-28952 Assertion `t->s->tmp_table || thd->mdl_context.is_lock_owner(MDL_key::TABLE, t->s->db.str, t->s->table_name.str, t->reginfo.lock_type >= TL_WRITE_ALLOW_WRITE ? MDL_SHARED_WRITE : MDL_SHARED_READ)' failed
-
- Closed
-
-
MDEV-28956 Locking is broken if CREATE OR REPLACE fails under LOCK TABLES
-
- Closed
-
- is blocked by
-
MDEV-28753 Review InnoDB changes for MDEV-25292
-
- Closed
-
- is part of
-
MDEV-25921 Implement CREATE TABLE...SELECT in one transaction
-
- Open
-
- relates to
-
MDEV-24576 Atomic CREATE TABLE
-
- Closed
-
-
MDEV-25595 DROP part of failed CREATE OR REPLACE is not written into binary log
-
- Closed
-