maria:bb-MDEV-21092-21095-29997-optimizer-trace-updates

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

6ef49c7... by Sergey Petrunia on 2022-12-08

MDEV-21095: Make Optimizer Trace support Index Condition Pushdown

Fixes over previous patches: do tracing of attached conditions
close to where we generate them.

Fix the tracing code to print the right conditions.

b6c5d74... by Rex Johnston on 2022-12-02

MDEV-21092,MDEV-21095,MDEV-29997: Optimizer Trace for index condition pushdown, partition pruning, exists-to-in

        Add Optimizer Tracing for:
        - Index Condition Pushdown
        - Partition Pruning
        - Exists-to-IN optimization

12786f0... by Marko Mäkelä on 2022-12-12

Merge 10.10 into 10.11

7ab42fd... by Marko Mäkelä on 2022-12-12

Merge 10.9 into 10.10

21ef68d... by Marko Mäkelä on 2022-12-12

Merge 10.8 into 10.9

5773725... by Marko Mäkelä on 2022-12-12

Merge 10.7 into 10.8

dbcbee1... by Marko Mäkelä on 2022-12-12

Merge 10.6 into 10.7

cf437f6... by Marko Mäkelä on 2022-12-12

Fix GCC -Og -Wmaybe-uninitialized

This fixes up commit dd5f4b3625def2ee74d8f9a6b55d1368ba597a84

c4d7939... by Marko Mäkelä on 2022-12-12

MDEV-30180 Server hang with innodb_undo_log_truncate=ON

trx_purge_truncate_history(): In case of an apparent conflict with
buf_pool_t::release_freed_page(), always momentarily acquire
buf_pool.mutex, to let the thread that is holding it and waiting for
buf_pool.flush_list_mutex to proceed.

The fix in commit c410f7aaea400eb98f13552725b685a2513aafcb was
insufficient, because simple yielding would not necessarily let
the conflicting thread to acquire buf_pool.flush_list_mutex.

This hang was reported and the fix tested by Axel Schwenke.

dd5f4b3... by Monty <email address hidden> on 2022-12-08

Fixed bug in Aria when used with enterprise mariadb-backup

If the backup finished in the middle of a Aria bulk load insert,
which could happen with LOAD DATA INFILE, CREATE ... SELECT etc)
there was a chance that Aria recovery would fail on the backup.

Fixed by ensuring that bulk load operations for Aria are not allowed
under BACKUP LOCK.
I also changed so that the table TRN is updated just before truncate
which ensures that old redo's for the table are ignored.
I also enabled Aria redo for DDL's to be able to repeat REPAIR commands.
Without this change recovery would not work on repaired tables.

Notes:
- We take the backup lock protection at the end of bulk insert (as we
  don't want to keep the lock over a very long running insert).
  If mariadb-backup keeps the backup lock too long, this may fail with
  a lock timeout. In this case the batch insert will fail and the table
  will be truncated (set to it's original state).