Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Categories: connectors experimental galera main
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

connectors experimental galera main
f6f5c6c3846f...
f6f5c6c3846faf3552797610919fce05de6ae820
Sergei Golubchik
13.0 deprecations

removed:

* DES encryption
* --secure-auth
* --old
* spider table options: bfz, btt, cmd, ctp, cwg, isa, ilm, ios, smd, stc, stl

extended under old-mode:

* YEAR(2), still available when old-mode=2_DIGIT_YEAR

un-deprecated:

* keep_files_on_create, originally (MDEV-23570) the idea was to make it
TRUE and deprecate. It cannot be removed when FALSE, but TRUE breaks
mariabackup.aria_backup where a table is altered from Aria to InnoDB
during a backup, so both t.MAD/t.MAI and t.ibd gets into a backup.
f0f5ef2c6aa9...
f0f5ef2c6aa9543158641cf935de5dd463e931ea
Marko Mäkelä
MDEV-38833 Suboptimal or dead code at server startup

The InnoDB bootstrap is creating unnecessary log checkpoints
and even invalidating the buffer pool for no reason, making it
necessary to read pages into the buffer pool during bootstrap.

Furthermore, the page cleaner thread attempts to invoke
recv_sys.apply(true), even though most calls were unreachable.

buf_flush_sync(): Replaced with buf_flush_sync_batch(LSN_MAX),
possibly preceded by recv_sys.apply(true).

buf_pool_t::assert_all_freed(): Assert that buf_pool.mutex is
being held by the caller.

buf_dblwr_t::create(): Evict each doublewrite buffer pooli page
immediately from the buffer pool, so that there will be no need
to invoke buf_pool_invalidate(). Also, remove the unnecessary
call to buf_flush_wait_flushed(); there is nothing special about
the doublewrite buffer creation ever since
commit e2c63a7062e3acbe44b8f7122c347183b87cbd89 (MDEV-38595)
made the redo logging actually crash-safe.

buf_pool_invalidate(): Moved to the same compilation unit with
the only remaining caller, recv_sys_t::apply().

srv_start(): Do not invoke buf_flush_sync(). We already created
an initial checkpoint in log_t::create(lsn_t), and we will create
the final one during shutdown. Together with the simplification of
buf_dblwr_t::create(), this should noticeably speed up the
server bootstrap. Also, simplify the log file rebuild by extending
the critical section of log_sys.latch and buf_pool.flush_list_mutex.

create_log_file(): Assert and assume that both log_sys.latch and
buf_pool.flush_list_mutex were acquired by the caller.
This prevents any race condition with buf_flush_page_cleaner()
when the log is being rebuilt.

srv_prepare_to_delete_redo_log_file(): Invoke recv_sys.apply(true)
and mark the recovery as completed, before checking for one more
precondition and invoking buf_flush_sync_batch(LSN_MAX).
Remove some duplicated assertions as well as a redundant call
to log_write_up_to() from the end. If we crash while rebuilding a
latest_format log file, the subsequent startup will perform
crash recovery normally. This avoids a redundant write to the old
log file during log file resizing.
ecaca269fdd7...
ecaca269fdd792c1f19381df361f21a0212780b2
Thirunarayanan Balathandayuthapani
MDEV-38832 Assertion `!commit_lsn' failed in void trx_t::free()

Problem:
========
When creating tables with vector indexes, if the secondary table
creation fails after the main table is successfully created,
the server was not properly cleaning up the main table's .ibd file.
When we try to do DROP DATABASE, the server sees an orphaned file
and attempts to clean up a "stale" handle. If
innodb_flush_log_later trx_commit=0 is set then the log buffer
is written to the file and flushed to disk only once per second.
Due to this reason, InnoDB doesn't reset trx->commit_lsn to 0.
This lead to assertion failure in trx_t::free()

Reason:
=======
This occurred because create_table_impl() always called
ddl_log_complete() on any error, which disables DDL log entries
instead of executing them for cleanup. The main table would be
left behind even though the overall CREATE TABLE operation failed.

Solution:
=========
ha_create_table(): Return error code 2 specifically when
secondary table creation for high-level indexes fails

create_table_impl(): Call ddl_log_revert() when error code is 2
to properly clean up the main table files.

innodb_drop_database(): Add debug assertion reset to clear
commit_lsn before freeing the transaction.
ec0520bbd27f...
ec0520bbd27f70ac4e4a1bb1d2425f6920d1f827
Nikita Malyavin
Fixes for review

elem_suits => match
init_one_table_no_request => init_one_table_no_mdl
malloc,realloc,free => my_malloc,...

insert_into_bucket made return void.

Using my_realloc resulted in that shrink can now return an error. The
reason is my_realloc can fail even if shrinking with SAFEMALLOC enabled.

SAFEMALLOC is enabled by default on non-windows builds.
cd20d5cef124...
cd20d5cef124085d7a1a9ef2bdd3dbd4c33a6f98
Thirunarayanan Balathandayuthapani
MDEV-37886  PAGE_COMPRESSED ALTER TABLE operations inconsistent with innodb_file_per_table setting

Problem:
=======
InnoDB DDL does ALTER TABLE PAGE_COMPRESSED=1 because:
1. check_if_supported_inplace_alter() reads srv_file_per_table
during precheck and does allow INSTANT operation.
2. User does change innodb_file_per_table later.
But prepare phase read srv_file_per_table again during execution.
3. If the global variable changed between these phases, causes
server abort for page_compressed tables.

Solution:
=========
- Add a file_per_table member to Alter_inplace_info to
capture the innodb_file_per_table value during the
precheck phase and use that consistent value throughout
the entire ALTER TABLE operation.
c63b2f1277b8...
c63b2f1277b8ae090a341705c365530440f602d3
Nikita Malyavin
optimize hash api to allow "insert if not found"
c4c13ad637db...
c4c13ad637dbeb3763725f33af3b76a64865797c
Aleksey Midenkov
MDEV-38815 Server crashes in Item_func_nextval::val_int upon update on a view

MDEV-28650 (7a88776dc1e) fixed the case when the DEFAULT flag is
inside the table definition but it can be also in DML command. When we
assign it from the table definition in mysql_make_view() we lose it in
the current command.

The fix does disjunction assignment to keep both values. It is
signalling DML_prelocking_strategy::handle_table() to call
add_internal_tables(), so it will correctly open associated sequence
table.
c20173a2e823...
c20173a2e823acce78ccc8f0c8a96e3ca05d0ee7
Thirunarayanan Balathandayuthapani
MDEV-37886  PAGE_COMPRESSED ALTER TABLE operations inconsistent with innodb_file_per_table setting

Problem:
=======
InnoDB DDL does ALTER TABLE PAGE_COMPRESSED=1 because:
1. check_if_supported_inplace_alter() reads srv_file_per_table
during precheck and does allow INSTANT operation.
2. User does change innodb_file_per_table later.
But prepare phase read srv_file_per_table again during execution.
3. If the global variable changed between these phases, causes
server abort for page_compressed tables.

Solution:
=========
- Add a file_per_table member to Alter_inplace_info to
capture the innodb_file_per_table value during the
precheck phase and use that consistent value throughout
the entire ALTER TABLE operation.
b9adbc666662...
b9adbc666662dc4bb862fd7ff93666ba76400f14
Mohammad Tafzeel Shams
MDEV-22186: Add innodb_buffer_pool_in_core_file to control buffer pool in cores

Problem:
There is no control to include or exclude the InnoDB buffer pool from core files,
which can lead to unnecessarily large core dumps or prevent capturing useful
memory state.

Solution:
Introduce a dynamic global system variable innodb_buffer_pool_in_core_file.
When set to OFF (or via --skip-innodb-buffer-pool-in-core-file),
the server attempts to exclude the buffer pool from core dumps using
madvise(MADV_DONTDUMP) where supported. If exclusion cannot be guaranteed,
@@core_file is automatically disabled and a warning is emitted to respect the
user’s intention.

- innodb_buffer_pool_in_core_file
  Determines whether the buffer pool should be included in core files when
  @@core_file=ON. No effect if @@core_file=OFF.
  Default: OFF on non-debug builds with MADV_DONTDUMP support, ON otherwise.

- innobase_should_madvise_buf_pool()
  Evaluates @@core_file and @@innodb_buffer_pool_in_core_file to determine if
  MADV_DONTDUMP should be applied.

- innobase_disable_core_dump()
  Clears TEST_CORE_ON_SIGNAL, disabling @@core_file when buffer pool exclusion
  cannot be guaranteed.

- buf_pool_t::madvise_dont_dump()
  Applies MADV_DONTDUMP to buffer pool memory. Emits warning and returns false
  if unsupported or fails.

- buf_pool_t::madvise_dump()
  Applies MADV_DODUMP to re-include buffer pool in core dumps. Returns false
  if unsupported or fails.

- buf_pool_t::madvise_update_dump()
  Reevaluates and updates madvise state. If exclusion fails, invokes
  innobase_disable_core_dump().

- buf_pool_t::buf_pool_should_madvise_dont_dump
  Tracks current dump state, protected by buf_pool_t::mutex.

- buf_pool_t::create()
  Initializes buf_pool_should_madvise_dont_dump and conditionally applies
  MADV_DONTDUMP after allocation; disables core dumps on failure.

- buf_pool_t::close()
  Calls madvise_dump() before releasing memory if MADV_DONTDUMP was applied.

- buf_pool_t::resize()
  Invokes madvise_update_dump(true) to reapply correct madvise state after
  resizing.

- innodb_srv_buffer_pool_in_core_file_update()
  Update hook that updates srv_buffer_pool_in_core_file and calls
  buf_pool.madvise_update_dump().

- srv_buffer_pool_in_core_file
  Global variable backing @@innodb_buffer_pool_in_core_file.

Inspired from mysql commit@891460995137598a6e0ae3684ba1cc6ccd0c3ca3
a4d739d1a504...
a4d739d1a50401db77873567a80754079ba5f83f
Mohammad Tafzeel Shams
MDEV-22186: Add innodb_buffer_pool_in_core_file to control buffer pool in cores

Problem:
There is no control to include or exclude the InnoDB buffer pool from core files,
which can lead to unnecessarily large core dumps or prevent capturing useful
memory state.

Solution:
Introduce a dynamic global system variable innodb_buffer_pool_in_core_file.
When set to OFF (or via --skip-innodb-buffer-pool-in-core-file),
the server attempts to exclude the buffer pool from core dumps using
madvise(MADV_DONTDUMP) where supported. If exclusion cannot be guaranteed,
@@core_file is automatically disabled and a warning is emitted to respect the
user’s intention.

- innodb_buffer_pool_in_core_file
  Determines whether the buffer pool should be included in core files when
  @@core_file=ON. No effect if @@core_file=OFF.
  Default: OFF on non-debug builds with MADV_DONTDUMP support, ON otherwise.

- innobase_should_madvise_buf_pool()
  Evaluates @@core_file and @@innodb_buffer_pool_in_core_file to determine if
  MADV_DONTDUMP should be applied.

- innobase_disable_core_dump()
  Clears TEST_CORE_ON_SIGNAL, disabling @@core_file when buffer pool exclusion
  cannot be guaranteed.

- buf_pool_t::madvise_dont_dump()
  Applies MADV_DONTDUMP to buffer pool memory. Emits warning and returns false
  if unsupported or fails.

- buf_pool_t::madvise_dump()
  Applies MADV_DODUMP to re-include buffer pool in core dumps. Returns false
  if unsupported or fails.

- buf_pool_t::madvise_update_dump()
  Reevaluates and updates madvise state. If exclusion fails, invokes
  innobase_disable_core_dump().

- buf_pool_t::buf_pool_should_madvise_dont_dump
  Tracks current dump state, protected by buf_pool_t::mutex.

- buf_pool_t::create()
  Initializes buf_pool_should_madvise_dont_dump and conditionally applies
  MADV_DONTDUMP after allocation; disables core dumps on failure.

- buf_pool_t::close()
  Calls madvise_dump() before releasing memory if MADV_DONTDUMP was applied.

- buf_pool_t::resize()
  Invokes madvise_update_dump(true) to reapply correct madvise state after
  resizing.

- innodb_srv_buffer_pool_in_core_file_update()
  Update hook that updates srv_buffer_pool_in_core_file and calls
  buf_pool.madvise_update_dump().

- srv_buffer_pool_in_core_file
  Global variable backing @@innodb_buffer_pool_in_core_file.

Inspired from mysql commit@891460995137598a6e0ae3684ba1cc6ccd0c3ca3
a4270c2c3585...
a4270c2c35850e764dedce86f48069204d10bbf8
Sergei Golubchik
MDEV-38811 crash in information_schema.table_constraints when --skip-grant-tables

acl_get_all3() wasn't expecting --skip-grant-tables
9bc4c051bf23...
9bc4c051bf23f04815676524ddafda0df9d4a6a1
Vladislav Vaintroub
x
998c03acaf9e...
998c03acaf9e6407782b09d70fb538994bafdcf8
Marko Mäkelä
MDEV-37949: Implement innodb_log_archive

TODO: Read all files with mmap() if innodb_log_file_mmap=ON, and
switch to pread() mode after recovery is completed. Remove or readjust
some code to read the checkpoint header from
log_t::archived_switch_recovery() while doing that. (For file-based I/O,
recv_sys_t::find_checkpoint() should just copy log_sys.checkpoint_buf to
log_sys.buf after reading the last file, and then restore it from there.)

TODO: Test and fix the crash-safety and recovery of SET GLOBAL
innodb_log_archive. Implement proper recovery when the file header of
ib_%016x.log is in the innodb_log_archive=OFF format. Ensure that
the start LSN of the ib_logfile0 will be written in a way that
is compatible with the already written log_sys.get_sequence_bit().

The InnoDB write-ahead log file (ib_logfile0) is pre-allocated to
innodb_log_file_size and written as a ring buffer. This is good for
write performance and space management, but unsuitable for arbitrary
point-in-time recovery or for facilitating incremental backup.

innodb_log_archive=ON: A new format where InnoDB will create and
preallocate files ib_%016x.log, instead of writing a circular file
ib_logfile0. Each file will be pre-allocated to
innodb_log_file_size<=4G. Once a log fills up, we will create and
pre-allocate another log file, to which log records will be
written. Upon the completion of the first log checkpoint in a recently
created log file, the old log file will be marked read-only, signaling
that there will be no further writes to that file, and that the file
may safely be moved to long-term storage.

The file name includes the log sequence number (LSN) at file offset
12288 (log_t::START_OFFSET). Limiting the file size to 4 GiB allows us
to identify each checkpoint by storing a 32-bit big-endian offset into
the optional FILE_MODIFY and the mandatory FILE_CHECKPOINT records,
between 12288 and the end of the file.

The innodb_encrypt_log format is identified by storing the encryption
information at the start of the log file. The first 32-bit value will
be 1, which is an invalid checkpoint offset. Each
innodb_log_archive=ON log must use the same encryption parameters.
Changing innodb_encrypt_log or related parameters is only possible by
setting innodb_log_archive=OFF and restarting the server, which will
permanently lose the history of the archived log.

The maximum number of log checkpoints that the innodb_log_archive=ON
file header can represent is limited to 12288/4=3072 when using
innodb_encrypt_log=OFF. If we run out of slots in a log file, each
subsequently completed checkpoint in that log file will overwrite the
last slot in the checkpoint header, until we switch to the next log.

innodb_log_recovery_start: The checkpoint LSN to start recovery from.
This will be useful when recovering from an archived log. This is useful
for restoring an incremental backup (applying InnoDB log files that were
copied since the previous restore).

innodb_log_recovery_target: The requested LSN to end recovery at.
When this is set, all persistent InnoDB tables will be read-only, and
no writes to the log are allowed. The intended purpose of this setting
is to prepare an incremental backup, as well as to allow data
retrieval as of a particular logical point of time.

Setting innodb_log_recovery_target>0 is much like setting
innodb_read_only=ON, with the exception that the data files may be
written to by crash recovery, and locking reads will conflict with any
incomplete transactions as necessary, and all transaction isolation
levels will work normally (not hard-wired to READ UNCOMMITTED).

srv_read_only_mode: When this is set (innodb_read_only=ON), also
recv_sys.rpo (innodb_log_recovery_target) will be set to the current LSN.
This ensures that it will suffice to check only one of these variables
when blocking writes to persistent tables.

The status variable innodb_lsn_archived will reflect the LSN
since when a complete InnoDB log archive is available. Its initial
value will be that of the new parameter innodb_log_archive_start.
If that variable is 0 (the default), the innodb_lsn_archived will
be recovered from the available log files. If innodb_log_archive=OFF,
innodb_lsn_archived will be adjusted to the latest checkpoint every
time a log checkpoint is executed. If innodb_log_archive=ON, the value
should not change.

The new setting SET GLOBAL innodb_log_archive=ON will enable log
archiving as soon as the current ib_logfile0 is about to wrap around.

SET GLOBAL innodb_log_archive=OFF will immediately rewrite the
checkpoint header in the latest ib_%016x.log and rename the file
to ib_logfile0.

When innodb_log_archive=ON, the setting SET GLOBAL innodb_log_file_size
will affect subsequently created log files when the file that is being
currently written is running out. If we are switching log files exactly
at the same time, then a somewhat misleading error message
"innodb_log_file_size change is already in progress" will be issued.

no_checkpoint_prepare.inc: A new file, to prepare for subsequent
inclusion of no_checkpoint_end.inc. We will invoke the server to
parse the log and to determine the latest checkpoint.

All --suite=encryption tests that use innodb_encrypt_log
will be skipped for innodb_log_encrypt=ON, because enabling
or disabling encryption on the log is not possible without
temporarily setting innodb_log_archive=OFF and restarting
the server. The idea is to add the following arguments to an
invocation of mysql-test/mtr:

--mysqld=--loose-innodb-log-archive \
--mysqld=--loose-innodb-log-recovery-start=12288 \
--mysqld=--loose-innodb-log-file-mmap=OFF \
--skip-test=mariabackup

Alternatively, specify --mysqld=--loose-innodb-log-file-mmap=ON
to cover both code paths.

The mariabackup test suite must be skipped when using the
innodb_log_archive=ON format, because mariadb-backup will only
support the old ib_logfile0 format (innodb_log_archive=OFF).

A number of tests would fail when the parameter
innodb_log_recovery_start=12288 is present, which is forcing
recovery to start from the beginning of the history
(the database creation). The affected tests have been adjusted with
explicit --innodb-log-recovery-start=0 to override that:

(0) Some injected corruption may be "healed" by replaying the log
from the beginning. Some tests expect an empty buffer pool after
a restart, with no page I/O due to crash recovery.
(1) Any test that sets innodb_read_only=ON would fail with an error
message that the setting prevents crash recovery, unless
innodb_log_recovery_start=0.
(2) Any test that changes innodb_undo_tablespaces would fail in crash
recovery, because crash recovery assumes that the undo tablespace ID
that is available from the undo* files corresponds with the start of
the log. This is an unforunate design bug which we cannot fix easily.

log_sys.first_lsn: The start of the current log file, to be consulted
in log_t::write_checkpoint() when renaming files.

log_sys.archived_lsn: New field: The value of innodb_lsn_archived.

log_sys.end_lsn: New field: The log_sys.get_lsn() when the latest
checkpoint was initiated. That is, the start LSN of a possibly empty
sequence of FILE_MODIFY records followed by FILE_CHECKPOINT.

log_sys.resize_target: The value of innodb_log_file_size that will be
used for creating the next archive log file once the current file (of
log_sys.file_size) fills up.

log_sys.archive: New field: The value of innodb_log_archive.

log_sys.next_checkpoint_no: Widen to uint16_t. There may be up to
12288/4=3072 checkpoints in the header.

log_sys.log: If innodb_log_archive=ON, this file handle will be kept
open also in the PMEM code path.

log_sys.resize_log: If innodb_log_archive=ON, we may have two log
files open both during normal operation and when parsing the log. This
will store the other handle (old or new file).

log_sys.resize_buf: In the memory-mapped code path, this will point
to the file resize_log when innodb_log_archive=ON.

recv_sys.log_archive: All innodb_log_archive=ON files that will be
considered in recovery.

recv_sys_t::find_checkpoint(): Find and remember the checkpoint position
in the last file when innodb_log_recovery_start points to an older file.

log_t::archive_new_write(): Create and allocate a new log file, and
write the outstanding data to both the current and the new file, or
only to the new file, until write_checkpoint() completes the first
checkpoint in the new file.

log_t::archived_mmap_switch_prepare(): Create and memory-map a new log
file, and update file_size to resize_target. Remember the file handle
of the current log in resize_log, so that write_checkpoint() will be
able to make it read-only.

log_t::archived_mmap_switch_complete(): Switch to the buffer that was
created in archived_mmap_switch_prepare().

log_t::write_checkpoint(): Allow an old checkpoint to be completed in
the old log file even after a new one has been created. If we are
writing the first checkpoint in a new log file, we will mark the old
log file read-only. We will also update log_sys.first_lsn unless it
was already updated in ARCHIVED_MMAP code path. In that code path,
there is the special case where log_sys.resize_buf == nullptr and
log_sys.checkpoint_buf points to log_sys.resize_log (the old log file
that is about to be made read-only). In this case, log_sys.first_lsn
will already point to the start of the current log_sys.log, even
though the switch has not been fully completed yet.

log_t::header_rewrite(my_bool): Rewrite the log file header before or
after renaming the log file. The recovery of the last ib_%016%.log
file must tolerate also the ib_logfile0 format.

log_t::set_archive(my_bool): Implement SET GLOBAL innodb_log_archive.
An error will be returned if non-archived SET GLOBAL innodb_log_file_size
(log file resizing) is in progress. The current log file will be renamed
to either ib_logfile0 or ib_%016x.log, as appropriate.

log_t::archive_set_size(): A new function, to ensure that
log_sys.resize_target is set on startup.

log_checkpoint_low(): Do not prevent a checkpoint at the start of a file.
We want the first innodb_log_archive=ON file to start with a checkpoint.

log_t::create(lsn_t): Initialize last_checkpoint_lsn. Initialize the
log header as specified by log_sys.archive (innodb_log_archive).

log_write_buf(): Add the parameter max_length, the file wrap limit.

log_write_up_to(), mtr_t::commit_log_release<bool mmap=true>():
If we are switching log files, invoke buf_flush_ahead(lsn, true)
to ensure that a log checkpoint will be completed in the new file.

mtr_t::finish_writer(): Specialize for innodb_log_archive=ON.

log_t::append_prepare<log_t::ARCHIVED_MMAP>(): Special case.

log_t::get_path(): Get the name of the current log file.

log_t::get_circular_path(size_t): Get the path name of a circular file.
Replaces get_log_file_path().

log_t::get_archive_path(lsn_t): Return a name of an archived log file.

log_t::get_next_archive_path(): Return the name of the next archived log.

log_t::append_archive_name(): Append the archive log file name
to a path string.

mtr_t::finish_writer(): Invoke log_close() only if innodb_log_archive=OFF.
In the innodb_log_archive=ON, we only force log checkpoints after creating
a new archive file, to ensure that the first checkpoint will be written
as soon as possible.

log_t::checkpoint_margin(): Replaces log_checkpoint_margin().
If a new archived log file has been created, wait for the
first checkpoint in that file.

srv_log_rebuild_if_needed(): Never rebuild if innodb_log_archive=ON.
The setting innodb_log_file_size will affect the creation of
subsequent log files. The parameter innodb_encrypt_log cannot be
changed while the log is in the innodb_log_archive=ON format.

log_t::attach(), log_mmap(): Add the parameter bool read_only.

recv_sys_t::find_checkpoint(): If the circular ib_logfile0 is missing,
determine the oldest archived log file with contiguous LSN.
If innodb_log_archive=ON, refuse to start if ib_logfile0 exists.
Open non-last archived log files in read-only mode.

recv_sys_t::find_checkpoint_archived(): Validate each checkpoint in
the current file header, and by default aim to recover from the last
valid one. Terminate the search if the last validated checkpoint
spanned two files. If innodb_log_recovery_start has been specified,
attempt to validate it even if there is no such information stored
in the checkpoint header.

log_parse_file(): Do not invoke fil_name_process() during
recv_sys_t::find_checkpoint_archived(), when we tolerate FILE_MODIFY
records while looking for a FILE_CHECKPOINT record.

recv_scan_log(): Invoke log_t::archived_switch_recovery() upon
reaching the end of the current archived log file.

log_t::archived_switch_recovery_prepare(): Make use of
recv_sys.log_archive and open all but the last file read-only.

log_t::archived_switch_recovery(): Switch files in the pread() code path.

log_t::archived_mmap_switch_recovery_complete(): Switch files in the
memory-mapped code path.

recv_warp: A pointer wrapper for memory-mapped parsing that spans two
archive log files.

recv_sys_t::parse_mmap(): Use recv_warp for innodb_log_archive=ON.

recv_sys_t::parse(): Tweak some logic for innodb_log_archive=ON.

log_t::set_recovered_checkpoint(): Set the checkpoint on recovery.
Updates also the end_lsn.

log_t::set_recovered_lsn(): Also update flush_lock and write_lock,
to ensure that log_write_up_to() will be a no-op.

log_t::clear_mmap(): Clean up the logic.

log_t::persist(): Even if the flushed_to_disk_lsn does not change,
we may want to reset the write_lsn_offset.
87309d3d4bb8...
87309d3d4bb8f48910d05b0ca5ee989bcdd6b053
Sergei Golubchik
MDEV-38811 crash in information_schema.table_constraints when --skip-grant-tables

acl_get_all3() wasn't expecting --skip-grant-tables
8288fd1cefd9...
8288fd1cefd9e7db5c1737c2ec4fecc95b986448
Vanislavsky
MDEV-30182: Optimize open_tables to take O(N) time

======
This is an  adopted version of patch provided in the PR #MariaDB/2680
Original author: Sergey Vanislavskiy
Adopted by: Nikita Maliavin
======

Table opening stage was known to make two list traversals:
1. In find_fk_prelocked_table, all the query_tables list is traversed for each
foreign key of a table to open.
2. MDL_context::find_ticket traverses all mdl tickets, one ticket per table.

Both result in O(tables^2) time total.
This may dramatically increase the query latencty in the following known cases:
* updates/deletes on tables with many children
* DMLs in transactions involving many different tables

Also, it slows down the DROP DATABASE performance, with a big enough amount of
tables.

So to optimize this out the following is done:
* A hash table with all FK-prelocked tables is added to THD. A table is filled
and queried inside find_fk_prelocked_table, and cleaned up at the query end.
* The find_ticket implementation is replaced with two consecutive hash lookups.
* A hash table with all tickets for current context (Query_tables_list) is
added.
* find_fk_prelocked_table now makes a hash lookup as well. We have to calculate
a hash value for this lookup, so MDL_key is created earlier. It's then reused
if a new table list is created.

Given the requirement of no performance degradation for a small table value,
a new data structure is introduced: Open_address_hash.

Open_address_hash is a generic data structure, that is optimized for usage with
a few elements, similarly to the "short string optimization" in c++ standard
libraries: if a number of elements can fit the structure's class body inline,
then they are placed there. One bit is borrowed to indicate whether the inline
mode is used.

This also means that this optimization cannot work in 32-bit environments.

The hash table is implemented from scratch using open address hashing to reduce
memory fragmentation, reduce allocation pressure and memory footprint.

Speaking of the memory footprint, it is expected to be as follows:
* +4x pointer size for each connection (2 pointers per hash, two hashes total)
* +4x pointer size for each prepared statement, or cached/exected stored
procedure.
* If number of tables opened > 2, then +2x pointer size per table, because the
hash load factor is kept 50% at this moment
* If number of FK-prelocked tables opened > 2, then +2x pointer size per
FK-prelocked table.
81be36e05df0...
81be36e05df02b6432d7f4c2e2ba65a78cb5942c
Sergei Golubchik
13.0 deprecations

removed:

* DES encryption
* --secure-auth
* --old
* spider table options: bfz, btt, cmd, ctp, cwg, isa, ilm, ios, smd, stc, stl

extended under old-mode:

* YEAR(2), still available when old-mode=2_DIGIT_YEAR

un-deprecated:

* keep_files_on_create, originally (MDEV-23570) the idea was to make it
TRUE and deprecate. It cannot be removed when FALSE, but TRUE breaks
mariabackup.aria_backup where a table is altered from Aria to InnoDB
during a backup, so both t.MAD/t.MAI and t.ibd gets into a backup.
7aed881560fc...
7aed881560fc970f59d444255fab715bf02cd838
Vladislav Vaintroub
x
758aa7aebc07...
758aa7aebc07be4d392b5fc7830c38a29c8e0e60
hadeer
mroonga: handle allocation for new_value in mrn_default_tokenizer_update

Align with existing mroonga memory management patterns to ensure consistency,
rather than relying on the MariaDB framework default behavior.
6b2562d8f911...
6b2562d8f911234f13edfc5eda2a0827d0b5a3bb
Pekka Lampio
MDEV-38385 Galera test failure on MDEV-30418

Fix for the sporadically failing MTR test "galera.MDEV-30418".
64b494c8a91c...
64b494c8a91c20ca8916ecba34797f51ff65f3c0
Marko Mäkelä
MDEV-38833 Suboptimal or dead code at server startup

The InnoDB bootstrap is creating unnecessary log checkpoints
and even invalidating the buffer pool for no reason, making it
necessary to read pages into the buffer pool during bootstrap.

Furthermore, the page cleaner thread attempts to invoke
recv_sys.apply(true), even though most calls were unreachable
starting with commit 685d958e38b825ad9829be311f26729cccf37c46 (MDEV-14425)
if not earlier.

buf_flush_sync(): Replaced with buf_flush_sync_batch(LSN_MAX),
possibly preceded by recv_sys.apply(true).

buf_pool_t::assert_all_freed(): Assert that buf_pool.mutex is
being held by the caller.

buf_dblwr_t::create(): Evict each doublewrite buffer pool page
immediately from the buffer pool, so that there will be no need
to invoke buf_pool_invalidate(). Also, remove the unnecessary
call to buf_flush_wait_flushed(); there is nothing special about
the doublewrite buffer creation ever since
commit e2c63a7062e3acbe44b8f7122c347183b87cbd89 (MDEV-38595)
made the redo logging actually crash-safe.

buf_pool_invalidate(): Moved to the same compilation unit with
the only remaining caller, recv_sys_t::apply().

srv_start(): Do not invoke buf_flush_sync(). We already created
an initial checkpoint in log_t::create(lsn_t), and we will create
the final one during shutdown. Together with the simplification of
buf_dblwr_t::create(), this should noticeably speed up the
server bootstrap. Also, simplify the log file rebuild by extending
the critical section of log_sys.latch and buf_pool.flush_list_mutex.

create_log_file(): Assert and assume that both log_sys.latch and
buf_pool.flush_list_mutex were acquired by the caller.
This prevents any race condition with buf_flush_page_cleaner()
when the log is being rebuilt.

srv_prepare_to_delete_redo_log_file(): Invoke recv_sys.apply(true)
and mark the recovery as completed, before checking for one more
precondition and invoking buf_flush_sync_batch(LSN_MAX).
Remove some duplicated assertions as well as a redundant call
to log_write_up_to() from the end. If we crash while rebuilding a
latest_format log file, the subsequent startup will perform
crash recovery normally. This avoids a redundant write to the old
log file during log file resizing.
6353c3fdc2fb...
6353c3fdc2fbc3d68aa8213be6aee7078b3121f2
Vladislav Vaintroub
x
610afdb2f97a...
610afdb2f97afdb3c005a5b9e246f91d2fe73b1f
Nikita Malyavin
optimize search in favor of erase for the "small hash table" case
5a590532cb06...
5a590532cb0607eee661a573b777c1697755d54a
Sergei Golubchik
13.0 deprecations

removed:

* DES encryption
* --secure-auth
* --old
* spider table options: bfz, btt, cmd, ctp, cwg, isa, ilm, ios, smd, stc, stl

extended under old-mode:

* YEAR(2), still available when old-mode=2_DIGIT_YEAR

un-deprecated:

* keep_files_on_create, originally (MDEV-23570) the idea was to make it
TRUE and deprecate. It cannot be removed when FALSE, but TRUE breaks
mariabackup.aria_backup where a table is altered from Aria to InnoDB
during a backup, so both t.MAD/t.MAI and t.ibd gets into a backup.
5a526eb99e5b...
5a526eb99e5b420ad9d836e3d17e6eb26a44189f
Daniel Bartholomew
bump the VERSION
588e95bb128c...
588e95bb128c94d976d560a4c10a53b781854ab9
Thirunarayanan Balathandayuthapani
MDEV-38832 Assertion `!commit_lsn' failed in void trx_t::free()

Problem:
========
When creating tables with vector indexes, if the secondary table
creation fails after the main table is successfully created,
the server was not properly cleaning up the main table's .ibd file.
When we try to do DROP DATABASE, the server sees an orphaned file
and attempts to clean up a "stale" handle. If
innodb_flush_log_later trx_commit=0 is set then the log buffer
is written to the file and flushed to disk only once per second.
Due to this reason, InnoDB doesn't reset trx->commit_lsn to 0.
This lead to assertion failure in trx_t::free()

Reason:
=======
This occurred because create_table_impl() always called
ddl_log_complete() on any error, which disables DDL log entries
instead of executing them for cleanup. The main table would be
left behind even though the overall CREATE TABLE operation failed.

Solution:
=========
ha_create_table(): Return error code 2 specifically when
secondary table creation for high-level indexes fails

create_table_impl(): Call ddl_log_revert() when error code is 2
to properly clean up the main table files.

innodb_drop_database(): Add debug assertion reset to clear
commit_lsn before freeing the transaction.
53739e40cd06...
53739e40cd065666aa00732a8155ecebeb27a9fb
Sergei Golubchik
13.0 deprecations

removed:

* DES encryption
* --secure-auth
* --old
* spider table options: bfz, btt, cmd, ctp, cwg, isa, ilm, ios, smd, stc, stl

extended under old-mode:

* YEAR(2), still available when old-mode=2_DIGIT_YEAR

un-deprecated:

* keep_files_on_create, originally (MDEV-23570) the idea was to make it
TRUE and deprecate. It cannot be removed when FALSE, but TRUE breaks
mariabackup.aria_backup where a table is altered from Aria to InnoDB
during a backup, so both t.MAD/t.MAI and t.ibd gets into a backup.
50c10d0c5237...
50c10d0c52372a299a1ad8d6aaaafd95ad5010e9
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Follow-up to extracion of common source code for events
487e7ef0d5a5...
487e7ef0d5a572149750abfe5905ba51a8405b33
Vladislav Vaintroub
wip
43e51e71112d...
43e51e71112d2064ead0f68a94449e046de31773
ParadoxV5
MDEV-4698 snapshot 6

This is most likely the last snapshot before rebasing to `main`.

* `@@relay_log_recovery` in GTID now delete old files to be safe.
* Fix the new relay log post perge still uses the old `Gtid_IO_Pos`
* Fix an existing oddity that GTID Lists
  (and many other non-group events) trigger slave delay,
  which causes `rpl.rpl_delayed_slave,parallel` to fail. Really?
  * Probably fixes MDEV-38825; gonna check it separately
  * Known existing oddity: In parallel replication,
    restart-skipped events also trigger slave delay;
    this causes `rpl.rpl_parallel_sbm` to hang. Really?
* Fix the event count of a trailing incomplete
  group not reset when purging the relay log
34a4500ca99f...
34a4500ca99fdf5762c22a529832611b233a5c29
Sergei Golubchik
MDEV-38587 slow_query_log missing from debian conf

add a line to actually enable slow query log, not only to
configure it
309b2f96f2bb...
309b2f96f2bb2846212bb3f4d2e3e64342cab89f
gkodinov
MDEV-38673: Focus the pick-a-task wording in CONTRIBUTING.md

The wording on how to pick a task in CONTRIBUTING.md is a bit weak.
A more focused message is needed to highlight the tasks that
are available for people to work on.
2dbd5bb326dd...
2dbd5bb326dd8bbdffb50d032f37763da9401e67
hadeer
Mroonga: Refactor variable_default_tokenizer_disable test

Add copyright header to the test file.
Disable the test in embedded mode by sourcing include/not_embedded.inc."
24ca18e2bf77...
24ca18e2bf7735c283fe5e6f29821f352222954e
Vladislav Vaintroub
x
1b4a940cc120...
1b4a940cc1200e4a4c0dd7d72a4c156f9a0420f5
Mohammad Tafzeel Shams
MDEV-22186: Add innodb_buffer_pool_in_core_file to control buffer pool in cores

Problem:
There is no control to include or exclude the InnoDB buffer pool from core files,
which can lead to unnecessarily large core dumps or prevent capturing useful
memory state.

Solution:
Introduce a dynamic global system variable innodb_buffer_pool_in_core_file.
When set to OFF (or via --skip-innodb-buffer-pool-in-core-file),
the server attempts to exclude the buffer pool from core dumps using
madvise(MADV_DONTDUMP) where supported. If exclusion cannot be guaranteed,
@@core_file is automatically disabled and a warning is emitted to respect the
user’s intention.

- innodb_buffer_pool_in_core_file
  Determines whether the buffer pool should be included in core files when
  @@core_file=ON. No effect if @@core_file=OFF.
  Default: OFF on non-debug builds with MADV_DONTDUMP support, ON otherwise.

- innobase_should_madvise_buf_pool()
  Evaluates @@core_file and @@innodb_buffer_pool_in_core_file to determine if
  MADV_DONTDUMP should be applied.

- innobase_disable_core_dump()
  Clears TEST_CORE_ON_SIGNAL, disabling @@core_file when buffer pool exclusion
  cannot be guaranteed.

- buf_pool_t::madvise_dont_dump()
  Applies MADV_DONTDUMP to buffer pool memory. Emits warning and returns false
  if unsupported or fails.

- buf_pool_t::madvise_dump()
  Applies MADV_DODUMP to re-include buffer pool in core dumps. Returns false
  if unsupported or fails.

- buf_pool_t::madvise_update_dump()
  Reevaluates and updates madvise state. If exclusion fails, invokes
  innobase_disable_core_dump().

- buf_pool_t::buf_pool_should_madvise_dont_dump
  Tracks current dump state, protected by buf_pool_t::mutex.

- buf_pool_t::create()
  Initializes buf_pool_should_madvise_dont_dump and conditionally applies
  MADV_DONTDUMP after allocation; disables core dumps on failure.

- buf_pool_t::close()
  Calls madvise_dump() before releasing memory if MADV_DONTDUMP was applied.

- buf_pool_t::resize()
  Invokes madvise_update_dump(true) to reapply correct madvise state after
  resizing.

- innodb_srv_buffer_pool_in_core_file_update()
  Update hook that updates srv_buffer_pool_in_core_file and calls
  buf_pool.madvise_update_dump().

- srv_buffer_pool_in_core_file
  Global variable backing @@innodb_buffer_pool_in_core_file.

Inspired from mysql commit@891460995137598a6e0ae3684ba1cc6ccd0c3ca3
1b225b6c027d...
1b225b6c027d877ebed0cbbb7b3b5a92ccc3c2cf
Thirunarayanan Balathandayuthapani
MDEV-37886  PAGE_COMPRESSED ALTER TABLE operations inconsistent with innodb_file_per_table setting

Problem:
=======
InnoDB DDL does ALTER TABLE PAGE_COMPRESSED=1 because:
1. check_if_supported_inplace_alter() reads srv_file_per_table
during precheck and does allow INSTANT operation.
2. User does change innodb_file_per_table later.
But prepare phase read srv_file_per_table again during execution.
3. If the global variable changed between these phases, causes
server abort for page_compressed tables.

Solution:
=========
- Add a file_per_table member to Alter_inplace_info to
capture the innodb_file_per_table value during the
precheck phase and use that consistent value throughout
the entire ALTER TABLE operation.
1885ceb036c2...
1885ceb036c297ba22c17efcb0a7114d3c9b6a7b
Pekka Lampio
MDEV-38385 Galera test failure on MDEV-30418

Fix for the sporadically failing MTR test "galera.MDEV-30418".
144b1da946bf...
144b1da946bfccfb8c3447063f849fcf1343c7ed
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Extracted common source code for events into the separate files
event_common.cc/event_common.h
0eefdb1b7612...
0eefdb1b7612009370f078bf6338ca57c99ae9a7
Nikita Malyavin
optimize hash api to allow "insert if not found"
0dde3e20e741...
0dde3e20e7416fa6b79e13f5cf332b5976b59c9f
Nikita Malyavin
optimize search in favor of erase for the "small hash table" case
060df29f008e...
060df29f008e58c711d3c530180b314233b4931f
Marko Mäkelä
MDEV-38833 Suboptimal or dead code at server startup

The InnoDB bootstrap is creating unnecessary log checkpoints
and even invalidating the buffer pool for no reason, making it
necessary to read pages into the buffer pool during bootstrap.

Furthermore, the page cleaner thread attempts to invoke
recv_sys.apply(true), even though most calls were unreachable
starting with commit 685d958e38b825ad9829be311f26729cccf37c46 (MDEV-14425)
if not earlier.

buf_flush_sync(): Replaced with buf_flush_sync_batch(LSN_MAX),
possibly preceded by recv_sys.apply(true).

buf_pool_t::assert_all_freed(): Assert that buf_pool.mutex is
being held by the caller.

buf_dblwr_t::create(): Evict each doublewrite buffer pool page
immediately from the buffer pool, so that there will be no need
to invoke buf_pool_invalidate(). Also, remove the unnecessary
call to buf_flush_wait_flushed(); there is nothing special about
the doublewrite buffer creation ever since
commit e2c63a7062e3acbe44b8f7122c347183b87cbd89 (MDEV-38595)
made the redo logging actually crash-safe.

buf_pool_invalidate(): Moved to the same compilation unit with
the only remaining caller, recv_sys_t::apply().

srv_start(): Do not invoke buf_flush_sync(). We already created
an initial checkpoint in log_t::create(lsn_t), and we will create
the final one during shutdown. Together with the simplification of
buf_dblwr_t::create(), this should noticeably speed up the
server bootstrap. Also, simplify the log file rebuild by extending
the critical section of log_sys.latch and buf_pool.flush_list_mutex.

create_log_file(): Assert and assume that both log_sys.latch and
buf_pool.flush_list_mutex were acquired by the caller.
This prevents any race condition with buf_flush_page_cleaner()
when the log is being rebuilt.

srv_prepare_to_delete_redo_log_file(): Invoke recv_sys.apply(true)
and mark the recovery as completed, before checking for one more
precondition and invoking buf_flush_sync_batch(LSN_MAX).
Remove some duplicated assertions as well as a redundant call
to log_write_up_to() from the end. If we crash while rebuilding a
latest_format log file, the subsequent startup will perform
crash recovery normally. This avoids a redundant write to the old
log file during log file resizing.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Sun 15 Feb 2026 15:24:43 (UTC)