Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2(EOL)
Description
Encryption must be properly tested with SPATIAL INDEX before 10.2 goes GA. I do not think that it can work in its current form. Note that MySQL 5.7 contains this change (to prepare for the repurposing of the field as FIL_RTREE_SPLIT_SEQ_NUM), but it does not retroactively clear the field to 0 on old files:
commit 8406d6aac3be6353bf693159ea0a5163edae0179
|
Author: Marko Mäkelä <marko.makela@oracle.com>
|
Date: Wed Jul 2 10:26:42 2014 +0300
|
|
WL#7990 Repurpose FIL_PAGE_FLUSH_LSN
|
|
The field FIL_PAGE_FLUSH_LSN is consulted during InnoDB startup.
|
|
At startup, InnoDB reads the FIL_PAGE_FLUSH_LSN from the first page of
|
each file in the InnoDB system tablespace. If there are multiple
|
files, the minimum and maximum LSN can differ. These numbers are
|
passed to InnoDB startup.
|
|
Having the number in other files than the first file of the InnoDB
|
system tablespace is not providing much additional value. It is
|
conflicting with other use of the field, such as on InnoDB R-tree
|
index pages.
|
|
The FIL_PAGE_FLUSH_LSN was also being written to InnoDB undo
|
tablespace files, even though the fields are not going to be consulted
|
on crash recovery.
|
|
This worklog will stop writing FIL_PAGE_FLUSH_LSN to other files
|
than the first file of the InnoDB system tablespace (page number 0:0).
|
Attachments
Issue Links
- causes
-
MDEV-12026 Support encrypted SPATIAL INDEX
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-