The error message modified.
Then the TABLE_SHARE::error_table_name() implementation taken from 10.3,
to be used as a name of the table in this message.
This patch changes how old rows in mysql.gtid_slave_pos* tables are deleted.
Instead of doing it as part of every replicated transaction in
record_gtid(), it is done periodically (every @@gtid_cleanup_batch_size
transaction) in the slave background thread.
This removes the deletion step from the replication process in SQL or worker
threads, which could speed up replication with many small transactions. It
also decreases contention on the global mutex LOCK_slave_state. And it
simplifies the logic, eg. when a replicated transaction fails after having
deleted old rows.
With this patch, the deletion of old GTID rows happens asynchroneously and
slightly non-deterministic. Thus the number of old rows in
mysql.gtid_slave_pos can temporarily exceed @@gtid_cleanup_batch_size. But
all old rows will be deleted eventually after sufficiently many new GTIDs
have been replicated.
main.derived_cond_pushdown: Move all 10.3 tests to the end,
trim trailing white space, and add an "End of 10.3 tests" marker.
Add --sorted_result to tests where the ordering is not deterministic.
main.win_percentile: Add --sorted_result to tests where the
ordering is no longer deterministic.
- Use the correct range bounds when doing a reverse-ordered range scan
(this was already done for HA_READ_PREFIX_LAST_OR_PREV but not for
HA_READ_BEFORE_KEY).
- Use the correct range bounds when doing a reverse-ordered range scan
(this was already done for HA_READ_PREFIX_LAST_OR_PREV but not for
HA_READ_BEFORE_KEY).
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).
This reverts commit 87609324e0
RocksDB was making invalid assumption about Field_blob::make_sort_key,
and the commit 87609324e0 changed Field_blob::make_sort_key to match
RocksDB assumptions.
It also unintentionaly broke sys_vars.max_sort_length_func
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.
The blob key length could be shorter than the length of the entire blob,
for example,
CREATE TABLE t1 (b BLOB, i INT, KEY(b(8)));
INSERT INTO t1 VALUES (REPEAT('a',9),1);
The key length is 8, while the blob length is 9.
So we need to set the correct key length in Field_blob::sort_string().
