MDEV-13512 buf_flush_update_zip_checksum() corrupts SPATIAL INDEX in ROW_FORMAT=COMPRESSED tables
In MariaDB Server 10.1, this problem manifests itself only as a debug assertion failure in page_zip_decompress() when an insert requires a page to be decompressed. In MariaDB 10.1, the encryption of InnoDB data files repurposes the previously unused field FILE_FLUSH_LSN for an encryption key version. This field was only used in the first page of each file of the system tablespace. For ROW_FORMAT=COMPRESSED tables, the field was always written as 0 until encryption was implemented. There is no bug in the encryption, because the buffer pool blocks will not be written to files. Instead, copies of the blocks will be encrypted. In these encrypted copies, the key version field will be updated before the buffer is written to the file. The field in the buffer pool is basically garbage that does not really matter. Already in MariaDB 10.0, the memset() calls to reset this unused field in buf_flush_update_zip_checksum() and buf_flush_write_block_low() are unnecessary, because fsp_init_file_page_low() would guarantee that the field is always 0 in the buffer pool (unless 10.1 encryption is used). Removing the unnecessary memset() calls makes page_zip_decompress() happy and will prevent a SPATIAL INDEX corruption bug in MariaDB Server 10.2. In MySQL 5.7.5, as part of WL#6968, the same field was repurposed for an R-tree split sequence number (SSN) and these memset() were removed. (Because of the repurposing, MariaDB encryption is not available for tables that contain SPATIAL INDEX.)
Showing
Please register or sign in to comment