Import complex XML from multiple files in MariaDB
Some row results are missing and replaced by the last file one.
Thats because Nx and Sx column members are not reset when changing file.
modified: storage/connect/tabxml.cpp
modified: storage/connect/tabxml.h
Re-enable main.mysql_client_test on all builders, because
at the moment we do not run any --big-test on buildbot
due to resource constraints.
A number of tests were declared big in
commit eeee1832d7
in an attempt to save resources on buildbot.
Stop masking the Data_free values, because innodb_file_per_table=1
is the default.
Also, do mask Update_time after updating tables, even though for
some reason it does appear to matter.
Cleanup install_layout to account for multi-arch setup and remove
redundant defines in debian rules.
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>
status threads_connected can temporarily be bigger than max_connections+1
If SHOW STATUS LIKE "Threads_connected" comes after
ER_CON_COUNT_ERROR is sent to the client, but before the counter is
decremented, Threads_connected can differ from the expected value.
added cmake checks for pam_ext.h and pam_appl.h headers
added check for pam_syslog()
added pam_syslog() if doesn't exist
all cmake checks performed from inside the plugin
join_cache_level=6+
The patch fixes two similar bugs in the commit 8eeb689e9f
that added multi_range_read support to partitions. The commit opened
a possibility to join a partition table using BKA+MRR. However in some
cases it could lead to wrong results or even crashes.
This could happened when
- index condition pushdown was used to join the table or
- the joined table was an inner table of an outer join and 'not exist'
optimization was applied or
- the join table was the inner table of a semi-join and the first match
optimization was applied
The bugs were in the code of the call-back functions
- partition_multi_range_key_skip_record() and
- partition_multi_range_key_skip_index_tuple().
Each of this function consist only of an invocation of another function.
Yet a wrong parameter was passed at this invocation.
The fix was suggested by Sergey Petrunia and it is apparently in line
with original design.
The corresponding comprehensive test cases demonstrating the problems
caused by the bugs were constructed by me.
If async replication slave thread conflicts with cluster replication,
then the async slave transaction should be BF aborted, and depending on the
state of async slave transaction execution, potentially also replayed.
There were problems in such BF abort implementation and the replaying was not
started.
This pull request contains fixes which make sure that if async slave thread is
marked to abort and replay, it will complete carry out the rollback and
release all locks and resources before starting the replaying. After replaying,
async slave transactions is treated as successful, so the slave thread will
continue as usual, handling next replication event.
There is also new mtr test: galera.galera_slave_replay, which stresses both a
certification failure for async slave thread and a successful BF abort
followed by replaying.
* `--defaults-file` option is showed only in `--help --verbose` if
applied
* `--default-extra-file` is showing correctly now in `--help --verbose`,
previously it was treated as a directory with appended `my.cnf`
Detecting the cpus based on sysconf of the online CPUs can significantly
over estimate the number of cpus available.
Wheither via numactl, cgroups, taskset, systemd constraints, docker
containers and probably other mechanisms, the number of threads mysqld
can be run on can be quite less.
As such we use the pthread_getaffinity_np function on Linux and FreeBSD
(identical API) to get the number of CPUs.
The number of CPUs is the default for the thread_pool_size and a too
high default will resulting in large memory usage and high context
switching overhead.
Closes PR #922
(Backport to 10.3)
Partitioning storage now supports MRR but doesn't support Index Condition
Pushdown (aka ICP). This causes counter-intuitive query plans for queries
that use BKA and conditions that depend on index fields:
- If the condition refers to other tables, BKA's variant of ICP is used
to handle it.
- If the condition depends on this table only, the optimizer will try to
use regular ICP for it, which will fail because the storage engine
doesn't support ICP.
Make the optimizer be smarter in the second case: if we were not able to
use regular ICP, use BKA's variant of ICP..
No functional changes.
Apply this in 10.3 so eventually it is merged to 10.4 and 10.5, which
in turn will have separate wrap-and-sort runs but only for new lines,
and not affecting badly next merges from 10.3 to 10.4 to 10.5.
Also remove a duplicate line that was found thanks to wrap-and-sort.
The Debian build tools add all run-time dependencies automatically. For the
mariadb-rocksdb-plugin the "${misc:Depends}, ${shlibs:Depends}" will become
(based on the build dependencies at build time):
Depends: mariadb-server-10.4 (= 1:10.4.12-1), rocksdb-tools,
libc6 (>= 2.29), liblz4-1 (>= 0.0~r130), libsnappy1v5 (>= 1.1.8),
libstdc++6 (>= 7), libzstd1 (>= 1.3.3), zlib1g (>= 1:1.1.4)
There is no need to manually add run-time build dependencies. Only external
dependencies need to be defined, for example rocksdb-tools could come in
question for mariadb-plugin-rocksdb, and it will be eventually added when
downstream official Debian packaging is merged upstream in a later commit.
