maria:bb-10.1-sujatha

Last commit made on 2019-09-21
Get this branch:
git clone -b bb-10.1-sujatha https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.1-sujatha
Repository:
lp:maria

Recent commits

95df67d... by Sujatha <email address hidden> on 2019-09-21

MDEV-18648: Testing worker_error propogation.

896974f... by varun on 2019-09-21

MDEV-18094: Query with order by limit picking index scan over filesort

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.

7a4019a... by Christian Hesse on 2019-03-01

MDEV-19207 systemd service: add instance name in description

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 <email address hidden>
makes it print:

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

6a7d51b... by Vicențiu Ciorbaru on 2019-09-20

MDEV-19211 Fix mysqld_safe --dry-run

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 <email address hidden>

13c2fd3... by Otto Kekäläinen on 2019-06-02

Deb: Implement proper version detection in maintainer scripts

Fixes bug introduced in commit 5415002.

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

8a79fa0... by THIRUNARAYANAN BALATHANDAYUTHAPANI on 2019-09-18

MDEV-19529 InnoDB hang on DROP FULLTEXT INDEX

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().

708f1e3... by THIRUNARAYANAN BALATHANDAYUTHAPANI on 2019-09-17

MDEV-19647 Server hangs after dropping full text indexes and restart

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

ae2b88f... by Igor Babaev on 2019-09-14

Adjusted test results after the change of a test case

0954bcb... by Igor Babaev on 2019-09-13

Post fix after the patch for MDEV-20576.

Adjusted test results.

deb9121... by Igor Babaev on 2019-09-13

MDEV-20576 A new assertion added to check validity of calculated
           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.