Last commit made on 2022-06-17
Get this branch:
git clone -b bb-10.9-mdev-27159

Branch merges

Branch information


Recent commits

a2c0e27... by Igor Babaev

MDEV-27159 Re-design the upper level of handling DML commands

This patch allows to execute only single-table and multi-table
UPDATE and DELETE statements using the method Sql_cmd_dml::execute().
The code that handles INSERT statements has not been touched.

9fe784f... by Marko Mäkelä

Merge 10.8 into 10.9

4c0cd95... by Marko Mäkelä

MDEV-28766: SET GLOBAL innodb_log_file_buffering

In commit c4c88307091cb16886562e9e7b77f5fd077d34b5 (MDEV-28111) we disabled
the file system cache on the InnoDB write-ahead log file (ib_logfile0)
by default on Linux.

It turns out that especially with innodb_flush_trx_log_at_commit=2,
writing to the log via the file system cache typically improves throughput,
especially on slow storage or at a small number of concurrent transactions.
For other values of innodb_flush_log_at_trx_commit, direct writes were
observed to be mostly but not always faster. Whether it pays off to
disable the file system cache on the log may depend on the type of storage,
the workload, and the operating system kernel version.

On Linux and Microsoft Windows, we will introduce the settable Boolean
global variable innodb_log_file_buffering that indicates whether the
file system cache on the redo log file is enabled. The default value is
innodb_log_file_buffering=OFF. If the server is started up with
innodb_flush_log_at_trx_commit=2, the value will be changed to

When a persistent memory interface is being used for the log,
the value cannot be changed from innodb_log_file_buffering=OFF.
On Linux, when the physical block size cannot be determined
to be a power of 2 between 64 and 4096 bytes, the file system cache
cannot be disabled, and innodb_log_file_buffering=ON cannot be changed.

Server log messages will indicate whether the file system cache is
enabled for the redo log:

[Note] InnoDB: Buffered log writes (block size=512 bytes)
[Note] InnoDB: File system buffers for log disabled (block size=512 bytes)

After this change, the startup parameter innodb_flush_method will no
longer control whether O_DIRECT will be set on the redo log on Linux.

On other operating systems that support O_DIRECT, no interface has been
implemented for controlling the file system cache for the redo log.
The innodb_flush_method values O_DIRECT, O_DIRECT_NO_FSYNC, O_DSYNC
will enable O_DIRECT for data files, not the log.

Tested by: Matthias Leich, Axel Schwenke

813986a... by Marko Mäkelä

Merge 10.7 into 10.8

42d3a7b... by Marko Mäkelä

Merge 10.6 into 10.7

6c82ab4... by Marko Mäkelä

MDEV-28840 innodb_undo_log_truncate is not crash-safe

trx_purge_free_segment(): Do mark that the block will be modified.

It seems possible that this regression was introduced by the
changes to the page-freeing logic
in commit 4179f93d28035ea2798cb1c16feeaaef87ab4775 (MDEV-18976).

Tested by: Matthias Leich


MDEV-25581 Allow user thread to do InnoDB fts cache sync

- innodb_fts.sync_block doesn't make sense after MDEV-25581's patch
because fts cache syncing is done as a part of insert operation
and it leads to completion of select over insert sometimes.
This test case is not relevant any more

ddf511c... by Marko Mäkelä

Merge 10.6 into 10.7

1f1fa7e... by Marko Mäkelä

Merge 10.5 into 10.6

4849d94... by Marko Mäkelä

MDEV-28828 SIGSEGV in buf_flush_LRU_list_batch

In commit 73fee39ea62037780c59161507e89dd76c10b7a3 (MDEV-27985)
a regression was introduced that would cause bpage=nullptr to
be referenced.

buf_flush_LRU_list_batch(): Always terminate the loop upon
encountering a null pointer.