Analysis: Flush changed page bitmaps calls log_online_follow_redo_log
that later calls log_group_read_log_seg with release_mutex = true
and that causes the log_sys mutex being released before
log_decrypt_after_read function that later required log_sys mutex.
Fix: Enter log_sys mutex before log_decrypt_after_read if mutex
is released and release the mutex after the function if we
acquired it before function call.
Introduce a new dummy INFORMATION_SCHEMA.CHANGED_PAGE_BITMAPS table to XtraDB
with reset_table callback to allow FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS
to be called from innobackupex.
Added new dynamic configuration variable innodb_buf_dump_status_frequency
to configure how often buffer pool dump status is printed in the logs.
A number between [0, 100] that tells how oftern buffer pool dump status
in percentages should be printed. E.g. 10 means that buffer pool dump
status is printed when every 10% of number of buffer pool pages are
dumped. Default is 0 (only start and end status is printed).
in cmake tests let's treat clang like gcc (same options,
same builtins) in many cases.
* don't check the compiler when
* testing for -fvisibility=hidden support
* testing for HAVE_ABI_CXA_DEMANGLE
* testing for HAVE_GCC_ATOMIC_BUILTINS
* when removing options with string(replace)
* when running ${CC} --version (ignore the error instead)
* run ABI checks for clang
* use "canonical" gcc flags for clang
* fix groonga too
Also:
* add cmake detection for gcc __atomic_* builtins. they might be
supported (__ATOMIC_SEQ_CST is defined), but not for all operand
sizes. In particular, 64-bit atomic load is problematic on i386
* cache check results for Windows
* remove the test for HAVE_CXXABI_H (HAVE_ABI_CXA_DEMANGLE is
suffifient)
Add progress info on InnoDB/XtraDB row0merge phase. Note that we
do not know exact number of rounds merge sort needs at start thus
also progress report might not be accurate.
Analysis: Problem was that actual payload size (page size) after compression
was handled incorrectly on encryption. Additionally, some of the variables
were not initialized.
Fixed by encrypting/decrypting only the actual compressed page size.
Analysis: Problem is that there is not enough temporary buffer slots
for pending IO requests.
Fixed by allocating same amount of temporary buffer slots as there
are max pending IO requests.
Analysis: Problem is that SQL-layer calls handler API after storage
engine has already returned error state. InnoDB does internal
rollback when it notices transaction error (e.g. lock wait timeout,
deadlock, etc.) and after this transaction is not naturally in
correct state to continue.
Fix: Do not continue fetch operations if transaction is not started.
Analysis: Problem is that both encrypted tables and compressed tables use
FIL header offset FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION to store
required metadata. Furhermore, for only compressed tables currently
code skips compression.
Fixes:
- Only encrypted pages store key_version to FIL header offset FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION,
no need to fix
- Only compressed pages store compression algorithm to FIL header offset FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION,
no need to fix as they have different page type FIL_PAGE_PAGE_COMPRESSED
- Compressed and encrypted pages now use a new page type FIL_PAGE_PAGE_COMPRESSED_ENCRYPTED and
key_version is stored on FIL header offset FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION and compression
method is stored after FIL header similar way as compressed size, so that first
FIL_PAGE_COMPRESSED_SIZE is stored followed by FIL_PAGE_COMPRESSION_METHOD
- Fix buf_page_encrypt_before_write function to really compress pages if compression is enabled
- Fix buf_page_decrypt_after_read function to really decompress pages if compression is used
- Small style fixes
Swap the key length when WORDS_BIGENDIAN is defined
Make the IOFF structure depending on WORDS_BIGENDIAN
modified: storage/connect/connect.cc
modified: storage/connect/xindex.h
