Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.4.3
Description
The test case for MDEV-18901 is revealing bugs in two components. While it is clear that MDEV-371 is the main cause of the regression, that task did not modify any InnoDB code.
InnoDB code was modified for implementing system-versioned tables. Hence, the assertion failure in InnoDB (reporting that indexes inside InnoDB are inconsistent with each other) could occur because of the changes for system-versioning, not directly because of MDEV-371.
Please try to find out if the system versioning code inside InnoDB is always handling errors correctly. As noted in MDEV-18272, on any error inside InnoDB, the minimum error handling should be to roll back the current row operation. Then it will be up to the SQL layer to roll back to the start of the statement or roll back the entire transaction.
For the test case, please refer to MDEV-18901 and use an affected revision of 10.4. I tested with commit 3568427d11f7afcd111b4c28c14cc8aba2b10807.
Attachments
Issue Links
- duplicates
-
MDEV-18967 Load data in system version with long unique does not work
- Closed
- is caused by
-
MDEV-371 Unique indexes for blobs
- Closed
- relates to
-
MDEV-18272 InnoDB fails to rollback after exceeding FOREIGN KEY recursion depth
- Closed
-
MDEV-18901 Wrong results after ADD UNIQUE INDEX(blob_column)
- Closed