Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Description
As noted in MDEV-15533, InnoDB can wrongly allow concurrent DML during a table-rebuilding ALTER TABLE statement when there is no PRIMARY KEY defined on the table.
I think that we should have an explicit check that DROP PRIMARY KEY is not allowed without ADD PRIMARY KEY. But if there was no key in the first place, apparently we are missing the check.
Not having a PRIMARY KEY is essentially causing the table to contain a hidden AUTO_INCREMENT like column as a hidden primary key. We refuse to add an AUTO_INCREMENT column online, and similarly we should refuse to rebuild PK-less tables online.
Attachments
Issue Links
- relates to
-
-
- Closed
-
On a second thought, this is not a bug. The DB_ROW_ID values will be inherited from the original table that is being rebuilt, or from the log of the concurrent DML operations. This class of operations simply is a table rebuild that preserves the current PRIMARY KEY. The ALTER TABLE operation has no need to assign any new PRIMARY KEY or DB_ROW_ID values.
DROP PRIMARY KEY without ADD PRIMARY KEY or adding an AUTO_INCREMENT column are totally different: they would have to deterministically map old PRIMARY KEY,DB_TRX_ID,DB_ROLL_PTR values from concurrent DML into DB_ROW_ID or AUTO_INCREMENT values. The practical choice is to disallow online operation.