• Marko Mäkelä's avatar
    MDEV-13512 buf_flush_update_zip_checksum() corrupts SPATIAL INDEX in ROW_FORMAT=COMPRESSED tables · f9b50c06
    Marko Mäkelä authored
    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.)
    f9b50c06
buf0flu.cc 87.5 KB