The parameter dup_chk_only was always passed as a constant false.
Remove the parameter and the dead code related to it.

In the function test_if_cheaper_ordering we make a decision if using an index is better than
using filesort for ordering. If we chose to do range access then in test_quick_select we
should make sure that cost for table scan is set to DBL_MAX so that it is not picked.

The unit files made systemd print:

systemd[1]: Started MariaDB 10.3.13 database server (multi-instance).

Let's add the instance name, so starting mariadb@foo.service
makes it print:

systemd[1]: Started MariaDB 10.3.13 database server (multi-instance foo).

mysqld_safe --dry-run needs to either call exit or return, depending if
it is being sourced or not, otherise return can lead to the error:

return: can only `return' from a function or sourced script

The original fix suggestion was proposed by FaramosCZ <mschorm@centrum.cz>

- Enable the test `sphinx.sphinx` which was disabled by MDEV 10986,
  comit ee0094d2
- Add test case to `sphinx.sphinx` to cover host as localhost instead of `127.0.0.1`
- Add result file for single test

There's an annoying bug that prevents a Sphinx table to connect to a searchd using a host name.
So the example table in the documentation https://mariadb.com/kb/en/library/about-sphinxse/#basic-usage that point's to "localhost" actually doesn't work.
After some investigation I found two errors. The first one is a wrong check after the getaddrinfo call. The second is a wrong usage of the returned struct.

Include comment header that describes overrides.

Unit description now includes @VERSION@.

After=syslog.target removed - redunant

Add --basedir=@prefix to prevent /root/.my.cnf lookups. This is
placed after $MYSQLD_OPTIONS in case a user sets a --{no,}default
type options which has to be first in the mysqld arguements.

Additional changes to multi instance (support-files/mariadb@.service.in):
* added @SYSTEMD_EXECSTARTPRE@ / @SYSTEMD_EXECSTARTPOST@
* removed mariadb@bootstrap reference as galera_new_cluster as
  it's a little too proment.
* use_galera_new_cluster.conf updated to override pre/post steps
  to ensure it has no side effects
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>

At commit, trx->lock.table_locks (which is a cache of trx_locks) can
consist of NULL pointers. Add a debug assertion for that, and clear
the vector.

The flag is_stat_field is not set for the min_value and max_value of field items
inside table share. This is a must requirement as we don't want to throw
warnings of truncation when we read values from the statistics table to the column
statistics of table share fields.

Fixes bug introduced in commit 54150029.

Using script run-time filename does not always work. One cannot assume
that the filename is always the same as there might be temporary file
names used by dpkg in certain situations. See Debian #920415.

The same fix has been successfully in use in Debian official packages
since February 2019:
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/6440c0d6e75

Problem:
=======
  During dropping of fts index, InnoDB waits for fts_optimize_remove_table()
and it holds dict_sys->mutex and dict_operaiton_lock even though the
table id is not present in the queue. But fts_optimize_thread does wait
for dict_sys->mutex to process the unrelated table id from the slot.

Solution:
========
  Whenever table is added to fts_optimize_wq, update the fts_status
of in-memory fts subsystem to TABLE_IN_QUEUE. Whenever drop index
wants to remove table from the queue, it can check the fts_status
to decide whether it should send the MSG_DELETE_TABLE to the queue.

Removed the following functions because these are all deadcode.
dict_table_wait_for_bg_threads_to_exit(),
fts_wait_for_background_thread_to_start(),fts_start_shutdown(), fts_shudown().

- There is no need to add the table in fts_optimize_wq if there is
no fts indexes associated with it.

Problem:
=======
  Transaction left with nonempty table locks list. This leads to
assumption that table_locks is not subset of trx_locks. Problem is that
lock_wait_timeout_thread() doesn't remove the table lock from
table_locks for transaction.

Solution:
========
  In lock_wait_timeout_thread(), remove the lock from table vector of
transaction.

Adjusted test results.

The test had been disabled in 10.2 due to frequent failures,
in 5ec9b88e.
After the problems were addressed, we failed to re-enable the test
until now.

Closes #739

When invoking option `--default-character-set=auto` character set
from underlying OS settings should be detected for mysqldump.

Command COM_SHUTDOWN was rejected in non-Primary because
server_command_flags[COM_SHUTDOWN] had value CF_NO_COM_MULTI
instead of CF_SKIP_WSREP_CHECK.

As a fix removed assignment
server_command_flags[CF_NO_COM_MULTI]= CF_NO_COM_MULTI
which overwrote server_command_flags[COM_SHUTDOWN].

           selectivity values fails

After having set the assertion that checks validity of selectivity values
returned by the function table_cond_selectivity() a test case from
order_by.tesst failed. The failure occurred because range optimizer could
return as an estimate of the cardinality of the ranges built for an index
a number exceeding the total number of records in the table.

The second bug is more subtle. It may happen when there are several
indexes with same prefix defined on the first joined table t accessed by
a constant ref access. In this case the range optimizer estimates the
number of accessed records of t for each usable index and these
estimates can be different. Only the first of these estimates is taken
into account when the selectivity of the ref access is calculated.
However the optimizer later can choose a different index that provides
a different estimate. The function table_condition_selectivity() could use
this estimate to discount the selectivity of the ref access. This could
lead to an selectivity value returned by this function that was greater
that 1.

On  Windows, during packaging step, if signing fails, retry
signtool again without timestamp parameter.

Fixes sporadic (rare) failures on buildbot

It is not reproducible, but the issue seems to be the same as with
MDEV-20490 and rocksdb.ttl_primary_read_filtering - a compaction caused
by DROP TABLE gets behind and compacts away the expired rows for the next
test. Fix this in the same way.

best_access_path() is called from two optimization phases:

1. Plan choice phase, in choose_plan(). Here, the join prefix being
   considered is in join->positions[]

2. Plan refinement stage, in fix_semijoin_strategies_for_picked_join_order
   Here, the join prefix is in join->best_positions[]

It used to access join->positions[] from stage #2. This didnt cause any
valgrind or asan failures (as join->positions[] has been written-to before)
but the effect was similar to that of reading the random data:
The join prefix we've picked (in join->best_positions) could have
nothing in common with the join prefix that was last to be considered
(in join->positions).

In mysql-server/commit@f46329044f8618212923bdf52e15d5b464201edc
the InnoDB function btr_cur_open_at_rnd_pos() was corrected so that
it would return a status that indicates whether the cursor was
successfully positioned. But this change was not correctly merged to
MariaDB in 2e814d47.

btr_cur_open_at_rnd_pos(): In the code path that was introduced in
MDEV-8588, properly return failure status.

No deterministic test case was found for this failure.
It was caught after removing the function
page_copy_rec_list_end_to_created_page() in a development branch.
As a result, the fill factor of index trees would improve, and
supposedly, so would the probability of btr_cur_open_at_rnd_pos()
reaching the intentionally corrupted page in the test
innodb.leaf_page_corrupted_during_recovery.
The wrong return value would cause
btr_estimate_number_of_different_key_vals() to wrongly invoke
btr_rec_get_externally_stored_len() on a non-leaf page and
trigger an assertion failure at the start of that function.

- During trx_undo_report_rename(), InnoDB can fail to write undo log
for it if undo log doesn't fit in the undo page. In that case, InnoDB
adds one more undo log page and retry to write the rename undo log.
But the assert is wrong and it doesn't allow to fail even for one time.

Null merge the MDEV-14383 fix; it affects 5.5 only.

there was a SELECT/DELETE race