maria:bb-11.2-MDEV-31411

Last commit made on 2023-11-02
Get this branch:
git clone -b bb-11.2-MDEV-31411 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-11.2-MDEV-31411
Repository:
lp:maria

Recent commits

5c5123d... by Rucha Deodhar <email address hidden>

MDEV-31411: JSON_ARRAY_INTERSECT/JSON_OBJECT_FILTER_KEYS should fetch
data from a table similar to other JSON functions

Analysis:
Since we are fetching values for every row ( because we are running SELECT
for all rows of a table ), correct value can be only obtained at the time of
calling val_int() because it is called to get value for each row.
Fix:
Set up hash for each row instead of doing it during fixing fields.

d0f8dfb... by Yuchen Pei <email address hidden>

Merge branch '11.1' into 11.2

9b2a65e... by Marko Mäkelä

Merge 11.0 into 11.1

be24e75... by Marko Mäkelä

Merge 10.11 into 11.0

f833ef5... by Marko Mäkelä

Merge 10.10 into 10.11

c857259... by Marko Mäkelä

Merge 10.6 into 10.10

bf7c6fc... by Marko Mäkelä

MDEV-32511 Assertion !os_aio_pending_writes() failed

In MemorySanitizer builds of 10.10 and 10.11, we would rather often
have the assertion fail in innodb_init() during mariadb-backup --prepare.
The assertion could also fail during InnoDB startup, but less often.

Before commit 685d958e38b825ad9829be311f26729cccf37c46 in 10.8 the
log file cleanup after a successfully applied backup is different,
and the os_aio_pending_writes() assertion is in srv0start.cc.

IORequest::write_complete(): Invoke node->complete_write() before
releasing the page latch, so that a log checkpoint that is about to
execute concurrently will not miss a fdatasync() or fsync() on the
file, in case this was the first write since the last such call.

create_log_file(), srv_start(): Replace the debug assertion with
a debug check. For all intents and purposes, all writes could have
been completed but some write_io_callback() may not have invoked
io_slots::release() yet.

2ecc044... by Marko Mäkelä

Merge 10.10 into 10.11

a49ebf7... by Monty <email address hidden>

Fixed memory leak when using histograms

This was introduced in last merge with 10.6
The reason is that 10.6 does not need anything special to free histograms
as everything is allocated on a memroot.
In 10.10 histograms is using the vector class, which has some problems:
- No automatic free
- No memory usage accounting
(we should at some point remove vector usage because of the above problem)

Fixed by expliciting freeing histograms when freeing TABLE_STATISTICS
objects.

0563106... by Marko Mäkelä

Merge 10.6 into 10.10