[MDEV-15249] Crash in MVCC read after IMPORT TABLESPACE Created: 2018-02-08 Updated: 2018-02-08 Resolved: 2018-02-08 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Storage Engine - XtraDB |
| Affects Version/s: | 10.0, 10.1, 10.2, 10.3 |
| Fix Version/s: | 10.0.35, 10.1.32, 10.2.13, 10.3.5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | corruption, upstream | ||
| Description |
|
The ALTER TABLE…IMPORT TABLESPACE operation that was originally introduced in MySQL 4.1 in a mostly useless form was improved in MySQL 5.6 so that it could actually import data files from other InnoDB installations. The import performs some adjustments to the data files. The DB_TRX_ID will be reset to refer to the transaction that is performing the import operation, and the DB_ROLL_PTR will be reset to 0. Until the IMPORT TABLESPACE transaction has been consumed by the purge_sys->view, other transactions whose read view was created before the IMPORT TABLESPACE would attempt to dereference the DB_ROLL_PTR, because the DB_TRX_ID should not exist in their read view, and they should attempt to fetch an older version. If the most significant bit of the DB_ROLL_PTR value were set, then the old transactions would consider the records as a ‘fresh insert’ of a later transaction, and correctly determine that the rows do not exist. (Note: with the fix of
The first SELECT would crash with an assertion failure due to trying to dereference the invalid DB_ROLL_PTR=0. |
| Comments |
| Comment by Marko Mäkelä [ 2018-02-08 ] | |||
|
For the record, the failing assertion is the same that was reported in
|