storage/rocksdb/rdb_datadic.cc: In member function 'int myrocks::Rdb_key_def::unpack_integer(myrocks::Rdb_field_packing*, Field*, uchar*, myrocks::Rdb_string_reader*, myrocks::Rdb_string_reader*) const'
storage/rocksdb/rdb_datadic.cc:1781:1: internal compiler error: Segmentation fault
}
on ppc64le, ubuntu bionic gcc 7.3.0 and debian stretch gcc 6.3.0
The error happens with -ftree-loop-vectorize when trying to vectorize
a particular loop (see Rdb_key_def::unpack_integer())
Compiler gets confused by __attribute__((optimize("O0")) that comes from
ha_rocksdb_proto.h. The intention of this __attribute__ was to prevent
function from being inlined (see ha_rocksdb.cc). Let's use a more
specific attribute that prevents inlining but does not confuse
loop vectorizer.
An error in "group commit with MariaDB's binlog" code: we would flush
the WAL even when the transaction did not do any writes (and so the logic
in myrocks::Rdb_transaction::commit caused it to rollback).
When counter increment is not within the expected range, print the number
instead of just FAIL.
This doesnt solve the bug but will help with the diagnostics.
Move up-to this revision in the upstream:
commit de1e8c7bfe7c875ea284b55040e8f3cd3a56fcc2
Author: Abhinav Sharma <abhinavsharma@fb.com>
Date: Thu Aug 23 14:34:39 2018 -0700
Log updates to semi-sync whitelist in the error log
Summary:
Plugin variable changes are not logged in the error log even when
log_global_var_changes is enabled. Logging updates to whitelist will help in
debugging.
Reviewed By: guokeno0
Differential Revision: D9483807
fbshipit-source-id: e111cda773d
commit de1e8c7bfe7c875ea284b55040e8f3cd3a56fcc2
Author: Abhinav Sharma <abhinavsharma@fb.com>
Date: Thu Aug 23 14:34:39 2018 -0700
Log updates to semi-sync whitelist in the error log
Summary:
Plugin variable changes are not logged in the error log even when
log_global_var_changes is enabled. Logging updates to whitelist will help in
debugging.
Reviewed By: guokeno0
Differential Revision: D9483807
fbshipit-source-id: e111cda773d
Currently RocksDB engine doesn't update AUTO_INCREMENT in the UPDATE statement.
For example,
CREATE TABLE t1 (pk INT AUTO_INCREMENT, a INT, PRIMARY KEY(pk)) ENGINE=RocksDB;
INSERT INTO t1 (a) VALUES (1);
UPDATE t1 SET pk = 3; ==> AUTO_INCREMENT should be updated to 4.
Without this fix, it hits the Assertion `dd_val >= last_val' failed in
myrocks::ha_rocksdb::load_auto_incr_value_from_index.
(cherry picked from commit f7154242b8)
The test causes simulated server crashes with DBUG_SUICIDE();.
It also relies on transactions that were committed right before the
crash to be visible after the crash (that is, it requires durability).
Run the test with transaction durability enabled: set
rocksdb-flush-log-at-trx-commit=1.
Compile on Windows MSVC with -DHAVE_SSE2 and -DHAVE_PCLMUL
It is safe, since code will do also runtime checks via cpuid(), before
using the instructions, and will fallback to slower versions,
if instructions are not available.
RocksDB will only build with libzstd support if libzstd version is
>=1.1.13. Unfortunately CMake's FindPackage claims it found version
1.1.13 when we have 1.1.12-1 installed, so a workaround with
CheckFunctionExists is used to properly check for correct libzstd
support.
Add variable rocksdb_remove_mariabackup_checkpoint.
If set, it will remove $rocksdb_datadir/mariabackup-checkpoint directory.
The variable is to be used by exclusively by mariabackup,
to remove temporary checkpoints.
Step#1: RocksDB files require a special #define when they are compiled
with valgrind. Without that, valgrind fails with an 'unimplemented syscall'
error for fcntl call.
Fix two issues:
1. Rdb_ddl_manager::rename() loses the value of m_hidden_pk_val. new
object used to get 0, which means "not loaded from the db yet".
2. ha_rocksdb::load_hidden_pk_value() uses current transaction (and its
snapshot) when loading hidden PK value from disk. This may cause it to
load an out-of-date value.
RocksDB now supports "iterator bounds" which are min and max keys
that an iterator is interested in.
Iterator initialization function doesn't copy the keys, though, it keeps
pointers to them.
So if the buffer space for the keys is used for another iterator (the one
for checking for UNIUQE constraint violation in ha_rocksdb::ha_update_row)
then one can get incorrect query result.
Fixed by using a separate buffer for iterator bounds in the unique constraint
violation check.
MariaDB has a scaled-down version of the test so we need to set
@@rocksdb_max_row_locks lower to trigger the desired error
(didn't catch this on test BB run because this test is marked as "big")
Bloom filter is only used when reading the data from disk. If the data
happens to be still in the memtable, bloomfilter wont be used.
Stabilize the testcase by making sure the data is on disk before we
read it.
Backport the fix from the upstream and add our testcase.
Backported cset:
commit 997a979bf5e2f75ab88781d9d3fd22dddc1fc21f
Author: Manuel Ung <mung@fb.com>
Date: Thu Feb 15 08:38:12 2018 -0800
Fix crashes in autoincrement code paths
Summary:
There are two issues related to autoincrement that can lead to crashes:
1. The max value for double/float type for autoincrement was not implemented in MyRocks, and can lead to assertions. The fix is to add them in.
2. If we try to set auto_increment via alter table on a table without an auto_increment column defined, we segfault because there is no index from which to read the last value. The fix is to perform a check to see if autoincrement exists before reading from index (similar to code ha_rocksdb::open).
Fixes https://github.com/facebook/mysql-5.6/issues/792
Closes https://github.com/facebook/mysql-5.6/pull/794
Differential Revision: D6995096
Pulled By: lth
fbshipit-source-id: 1130ce1
