Last commit made on 2022-07-29
Get this branch:
git clone -b 10.9

Branch merges

Branch information


Recent commits

bfdc4ff... by Rucha Deodhar <email address hidden>

MDEV-28762: recursive call of some json functions without stack control

Fixup to MDEV-28762. Fixes warnings about unused variable "stack_used_up"
during building with RelWithDebInfo

f53f64b... by Marko Mäkelä

Merge 10.8 into 10.9

f79cebb... by Marko Mäkelä

Merge 10.7 into 10.8

1630037... by Marko Mäkelä

MDEV-27774 fixup: log_sys.mutex is log_sys.latch

742e1c7... by Marko Mäkelä

Merge 10.6 into 10.7

3091438... by Marko Mäkelä

Merge 10.5 into 10.6

098c0f2... by Marko Mäkelä

Merge 10.4 into 10.5

e5c4f4e... by Marko Mäkelä

Merge 10.3 into 10.4

0ee1082... by Marko Mäkelä

MDEV-28495 InnoDB corruption due to lack of file locking

Starting with commit da094188f60bf67e3d90227304a4ea256fe2630f (MDEV-24393),
MariaDB will no longer acquire advisory file locks on InnoDB data
files by default, because it would create a large number of
entries in Linux /proc/locks.

The motivation for acquiring the file locks is to prevent accidental
concurrent startup of multiple server processes on the same data files.
Such mistake still turns out to be relatively common, based on
corruption bug reports from the community.

To prevent corruption due to concurrent startup attempts, the
Aria storage engine would unconditionally acquire an advisory lock
on one of its log files.

Solution: InnoDB will always lock its system tablespace files.
(Ever since commit 685d958e38b825ad9829be311f26729cccf37c46
the InnoDB log file will not necessarily be open while the
server is running, because it can be accessed via memory-mapped I/O.)

If more protection is desired, then the option --external-locking
can be used.

The mandatory advisory lock also fixes intermittent failures of
some crash recovery tests. It turns out that when the mtr test harness
kills and restarts the server, it will not actually ensure that the
old process has terminated before starting the new one.

3bb36e9... by Oleksandr "Sanja" Byelkin

Merge branch '10.3' into 10.4