maria:bb-10.4-MDEV-25869

Last commit made on 2021-06-07
Get this branch:
git clone -b bb-10.4-MDEV-25869 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.4-MDEV-25869
Repository:
lp:maria

Recent commits

6ef55d9... by Marko Mäkelä

MDEV-25869 Change buffer entries are lost on InnoDB restart

buf_read_ibuf_merge_pages(): If space->size is 0, invoke
fil_space_get_size() to determine the size of the tablespace
by reading the header page. Only after that proceed to delete
any entries that are beyond the end of the tablespace.
Otherwise, we could be deleting valid entries that actually
need to be applied.

This fixes a regression that had been introduced in
commit b80df9eba23b4eb9694e770a41135127c6dbc5df (MDEV-21069),
which aimed to avoid crashes during DROP TABLE of corrupted tables.

ddddfc3... by Anel Husakovic <email address hidden>

Fix mtr tests with file_key_managment extension for Windows

Commit b5615eff0d00 introduced comment in result file during shutdown.
In case of Windows for the tests involving `file_key_managment.so` as plugin-load-add the tests will be overwritten with .dll extension.
The same happens with environment variable `$FILE_KEY_MANAGMENT_SO`.
So the patch is removing the extension to be extension agnostic.

Reviewed by: <email address hidden>

bab4348... by Marko Mäkelä

Merge 10.3 into 10.4

2d38c5e... by Marko Mäkelä

MDEV-17749 fixup: ./mtr --embedded main.lock_kill (again)

385f431... by Igor Babaev

Corrected the test case of MDEV-25714 in order to have the same EXPLAIN output as in 10.3

0b79713... by Igor Babaev

MDEV-25714 Join using derived with aggregation returns incorrect results

If a join query uses a derived table (view / CTE) with GROUP BY clause then
the execution plan for such join may employ split optimization. When this
optimization is employed the derived table is not materialized. Rather only
some partitions of the derived table are subject to grouping. Split
optimization can be applied only if:
- there are some indexes over the tables used in the join specifying the
  derived table whose prefixes partially cover the field items used in the
  GROUP BY list (such indexes are called splitting indexes)
- the WHERE condition of the join query contains conjunctive equalities
  between columns of the derived table that comprise major parts of
  splitting indexes and columns of the other join tables.

When the optimizer evaluates extending of a partial join by the rows of the
derived table it always considers a possibility of using split optimization.
Different splitting indexes can be used depending on the extended partial
join. At some rare conditions, for example, when there is a non-splitting
covering index for a table joined in the join specifying the derived table
usage of a splitting index to produce rows needed for grouping may be still
less beneficial than usage of such covering index without any splitting
technique. The function JOIN_TAB::choose_best_splitting() must take this
into account.

Approved by Oleksandr Byelkin <email address hidden>

663bc84... by Igor Babaev

MDEV-25714 Join using derived with aggregation returns incorrect results

If a join query uses a derived table (view / CTE) with GROUP BY clause then
the execution plan for such join may employ split optimization. When this
optimization is employed the derived table is not materialized. Rather only
some partitions of the derived table are subject to grouping. Split
optimization can be applied only if:
- there are some indexes over the tables used in the join specifying the
  derived table whose prefixes partially cover the field items used in the
  GROUP BY list (such indexes are called splitting indexes)
- the WHERE condition of the join query contains conjunctive equalities
  between columns of the derived table that comprise major parts of
  splitting indexes and columns of the other join tables.

When the optimizer evaluates extending of a partial join by the rows of the
derived table it always considers a possibility of using split optimization.
Different splitting indexes can be used depending on the extended partial
join. At some rare conditions, for example, when there is a non-splitting
covering index for a table joined in the join specifying the derived table
usage of a splitting index to produce rows needed for grouping may be still
less beneficial than usage of such covering index without any splitting
technique. The function JOIN_TAB::choose_best_splitting() must take this
into account.

Approved by Oleksandr Byelkin <email address hidden>

fa0bbff... by Monty <email address hidden>

Fixed that compile-pentium64-valgrind-max works

- Removed Tokudb (no need to test this anymore with valgrind)
- Added __attribute__(unused)) to a few places to be able to compile even
  if valgrind/memcheck.h is not installed.

Reviewer: Marko Mäkelä <email address hidden>

d3d2c96... by Marko Mäkelä

Merge 10.3 into 10.4

aa70690... by Marko Mäkelä

Merge 10.2 into 10.3