[MDEV-23310] InnoDB fails to refuse ALTER ONLINE TABLE when no PRIMARY KEY exists Created: 2020-07-28 Updated: 2020-07-28 Resolved: 2020-07-28 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Data Definition - Alter Table, Storage Engine - InnoDB |
| Affects Version/s: | 10.0, 10.1, 10.2, 10.3, 10.4, 10.5 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | corruption, online-ddl | ||
| Issue Links: |
|
||||||||
| Description |
|
As noted in 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. |
| Comments |
| Comment by Marko Mäkelä [ 2020-07-28 ] |
|
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. |