[MDEV-20073] ALGORITHM=INSTANT fails while adding new column Created: 2019-07-16  Updated: 2021-11-26

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.4.6
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Maikel Punie Assignee: Marko Mäkelä
Resolution: Unresolved Votes: 1
Labels: innodb


 Description   

when trying to add a column to a big innodb table we get an error saying the column type can not be changed with ALGORITHM=INSTANT, but we are trying to add a column.

MariaDB [regressiondb]> show create table testAndSuite_status\G
*************************** 1. row ***************************
       Table: testAndSuite_status
Create Table: CREATE TABLE `testAndSuite_status` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `topo_id` int(10) unsigned NOT NULL,
  `vmTopo_id` int(10) unsigned NOT NULL DEFAULT 0,
  `extraKey_id` int(10) NOT NULL DEFAULT 0,
  `testAndSuite_id` int(10) unsigned NOT NULL,
  `status` enum('PASSED','FAILED','SKIPPED','UNKNOWN','OUT','GHOST') COLLATE latin1_bin NOT NULL DEFAULT 'GHOST',
  `rotten` tinyint(1) NOT NULL DEFAULT 0,
  `duration` varchar(45) COLLATE latin1_bin DEFAULT NULL,
  `regressRun_id_Pass` int(11) DEFAULT NULL,
  `regressRun_id_Fail` int(11) DEFAULT NULL,
  `origin` enum('scanResult','scanGash','admin','gui','expand') COLLATE latin1_bin NOT NULL,
  `registered` tinyint(1) NOT NULL DEFAULT 0,
  `changedDate` timestamp NOT NULL DEFAULT current_timestamp(),
  `remarks` varchar(140) COLLATE latin1_bin DEFAULT NULL,
  `passCount` int(11) NOT NULL DEFAULT 0,
  `failCount` int(11) NOT NULL DEFAULT 0,
  `bossKey` tinyint(1) NOT NULL,
  `aggregate` int(2) NOT NULL DEFAULT 0 COMMENT '0=normal, 2=agg, 1=pointing to agg',
  PRIMARY KEY (`id`),
  KEY `testAndSuite` (`testAndSuite_id`),
  KEY `topo` (`topo_id`),
  KEY `regressRun_id_Fail` (`regressRun_id_Fail`),
  KEY `regressRun_id_Pass` (`regressRun_id_Pass`),
  KEY `rotten` (`rotten`),
  KEY `extrakey` (`extraKey_id`),
  KEY `vmTopo_id` (`vmTopo_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2717022889 DEFAULT CHARSET=latin1 COLLATE=latin1_bin
1 row in set (0.000 sec)
 
MariaDB [regressiondb]> alter table testAndSuite_status ADD master_tas_id INT(11) UNSIGNED NULL DEFAULT NULL, ALGORITHM=INSTANT;
ERROR 1846 (0A000): ALGORITHM=INSTANT is not supported. Reason: Cannot change column type. Try ALGORITHM=COPY
 
MariaDB [regressiondb]> select VERSION();
+--------------------+
| VERSION()          |
+--------------------+
| 10.4.6-MariaDB-log |
+--------------------+
1 row in set (0.000 sec)
 
MariaDB [regressiondb]> show variables like '%row_format%';
+---------------------------+---------+
| Variable_name             | Value   |
+---------------------------+---------+
| innodb_default_row_format | dynamic |
+---------------------------+---------+
1 row in set (0.002 sec)



 Comments   
Comment by Maikel Punie [ 2019-07-29 ]

Any update on this one?
its blocking us at the moment

Comment by Yitzchak [ 2021-07-08 ]

I am also having this happen, in an amazon rds instance with version 10.4.18. It would be nice to know if there's something about the particular table or replication or something that causes this behavior?

After doing (in a restored snapshot) `alter table tablename force;`, I can add columns without locking. Is there anything I can do to make it work in my main db?

Comment by Yitzchak [ 2021-07-08 ]

This seems to be a problem with (some, but not all, and I would love to know what the underlying problem is) tables built (or last fully altered) under an earlier version of mariadb/innodb.

{{MariaDB [shiftboard_com_2]> alter online table coverage_snapshot add publish_date_utc datetime;
ERROR 1846 (0A000): LOCK=NONE is not supported. Reason: Cannot change column type. Try LOCK=SHARED
MariaDB [shiftboard_com_2]> alter table coverage_snapshot force;
Query OK, 459586 rows affected (1 min 33.09 sec)
Records: 459586 Duplicates: 0 Warnings: 0

MariaDB [shiftboard_com_2]> alter online table coverage_snapshot add publish_date_utc datetime;
Query OK, 0 rows affected (0.16 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [shiftboard_com_2]> select version();
---------------------

version()

---------------------

10.4.13-MariaDB-log

---------------------
1 row in set (0.00 sec)}}

If that is correct, is there a way to determine which tables will have this problem?

Generated at Thu Feb 08 08:56:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.