Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3.2
Description
The following change to the MDEV-17196 test fails with every innodb_page_size:
diff --git a/mysql-test/suite/innodb/t/instant_alter.test b/mysql-test/suite/innodb/t/instant_alter.test
|
index 720e495e3a7..dc7a56fb641 100644
|
--- a/mysql-test/suite/innodb/t/instant_alter.test
|
+++ b/mysql-test/suite/innodb/t/instant_alter.test
|
@@ -338,8 +338,7 @@ ALGORITHM=INSTANT;
|
SET foreign_key_checks=1;
|
ALTER TABLE t2 COMMENT 'domestic keys only', DROP FOREIGN KEY fk;
|
ALTER TABLE t1 DROP FOREIGN KEY t1_ibfk_1;
|
-ALTER TABLE t1 ADD COLUMN big BLOB NOT NULL
|
-DEFAULT REPEAT('a', @@GLOBAL.innodb_page_size * .75);
|
+ALTER TABLE t1 ADD COLUMN big BLOB NOT NULL DEFAULT REPEAT('a', 65535);
|
CHECK TABLE t2, t1;
|
DROP TABLE t2, t1;
|
|
10.3 aba5c72be28cbd3028623070b7bf3d7d1e128be1 |
CURRENT_TEST: innodb.instant_alter
|
mysqltest: At line 341: query 'ALTER TABLE t1 ADD COLUMN big BLOB NOT NULL DEFAULT REPEAT('a', 65535)' failed: 1713: Undo log record is too big
|
We seem to be attempting to write the default value to the undo log record.
Unlike MDEV-17126, it could be possible to fix this without changing the undo log format.
Work-arounds:
- Assign shorter default values
- Add , FORCE so that the table will be rebuilt (non-instant operation)
Attachments
Issue Links
- blocks
-
MDEV-17383 BLOB leak when emptying an instantly altered table
- Open
- is caused by
-
MDEV-11369 Instant add column for InnoDB
- Closed
- relates to
-
MDEV-17126 UPDATE of a BLOB column with long DEFAULT value fails
- Confirmed
-
MDEV-17196 Crash during instant ADD COLUMN with long DEFAULT value
- Closed
I believe that fixing this requires an undo log format change.
MDEV-17197-WIP-10.3-7e869a2767c849d266ffbf1def9b93ffae7cd428.patch modifies trx_undo_page_report_modify() so that no data field contents is written for adding a column to the metadata record. This would cause an assertion failure during rollback, in the function btr_cur_trim(). Rollback depends on the presence of the default value in the undo log record. The function btr_cur_trim() would remove trailing fields from the metadata record during rollback.
It seems that instead of copying the default values to the undo log record or omitting the values altogether, we should write something special that allows the equivalent of btr_cur_trim() to be performed during rollback.
Because long default values should be rare in practice, and because this bug does not cause any corruption, I do not think that it is feasible to fix this in the stable 10.3 series. The bug can be worked around by not specifying long DEFAULT values for instantly added columns, or by adding the , FORCE keyword, so that the table will be rebuilt instead of performing instant ADD COLUMN.