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
f69baae46dc9...
f69baae46dc940b662553060136ecbf9f0ec5ea8
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Follow-up to update result file for the test is_columns_mysql_embedded
that is run against embedded server.
f4b0149a5932...
f4b0149a5932f2fec619e1e3b96fd243a7c75705
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
f097d45cadda...
f097d45caddaa07697c4aeefc9e428f2cc6a0181
Marko Mäkelä
fixup! 998c03acaf9e6407782b09d70fb538994bafdcf8
db5ec46b369e...
db5ec46b369e596e0253b48498163ac39b5c0b1a
Georg Richter
Refactor ma_stmt_execute_generate_simple_request() to precompute
the exact packet size and build the execute request in a single
buffer allocation.

Fix packed_len for temporal types
d046c6aae2a0...
d046c6aae2a080328d0d65f29696f9f89ee313c1
Thirunarayanan Balathandayuthapani
MDEV-38832 Assertion `!commit_lsn' failed in void trx_t::free()

Problem:
=======
- During drop table, InnoDB fails to remove the table entries
  from InnoDB statistics table when stats_persistent is disabled.
  Later, When we try to do DROP DATABASE, the server removes the stale
  entries from statistics table. 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()

Solution:
========
innodb_drop_database(): Add debug assertion reset to clear
commit_lsn before freeing the transaction.
This also fixes the merge commit 40f708466147a9942121e46965bd7c7006ce4e84
c380e165973d...
c380e165973db1d06826801883df8613ac333947
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)
before invoking buf_flush_sync_batch(LSN_MAX).
Remove a redundant call to fil_system.sys_space->open(false)
because srv_start() must already have successfully invoked that
in order for us to reach this code path. 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.
b881bdc5d35a...
b881bdc5d35a732bd8492561ee5930d98bb76534
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
b411226c08a2...
b411226c08a2ad037f2dc1184fa291223cf21eca
Oleg Smirnov
MDEV-38045: Implement implicit query block names for optimizer hints

This patch implements support for implicit query block (QB) names in
optimizer hints, allowing hints to reference query blocks and tables
within derived tables, views and CTEs without requiring explicit
QB_NAME hints.

Examples.
-- Addressing a table inside a derived table using implicit QB name
select /*+ no_index(t1@dt) */ *
  from (select * from t1 where a > 10) as DT;
-- this is an equivalent to:
select /*+ no_index(t1@dt) */ * from
  (select /*+ qb_name(dt)*/ * from t1 where a > 10) as DT;
-- Addressing a query block corresponding to the derived table
select /*+ no_bnl(@dt) */ *
  from (select * from t1, t2 where t.1.a > t2.a) as DT;

-- View
create view v1 as select * from t1 where a > 10 and b > 100;
-- referencing a table inside a view by implicit QB name:
select /*+ index_merge(t1@v1 idx_a, idx_b) */ *
  from v1, t2 where v1.a = t2.a;
-- equivalent to:
create view v1 as select /*+ qb_name(qb_v1) */ *
  from t1 where a > 10 and b > 100;
select /*+ index_merge(t1@qb_v1 idx_a, idx_b) */ *
  from v1, t2 where v1.a = t2.a;

-- CTE
with aless100 as (select a from t1 where b <100)
  select /*+ index(t1@aless100) */ * from aless100;
-- equivalent to:
with aless100 as (select /*+ qb_name(aless100) */ a from t1 where b <100)
  select /*+ index(t1@aless100) */ * from aless100;

Key changes:

1. Two-stage hint resolution
  - Introduced hint_resolution_stage enum (EARLY/LATE) to control
    when different hint types are resolved:
    - EARLY stage: first-order hints (QB_NAME, MERGE hints)
    - LATE stage: second-order hints (all other hints)

2. Implicit QB name support
  - Derived table/view/CTE aliases can now be used as implicit query
    block names in hint syntax: @alias, table@alias
  - Derived tables inside views can be addressed from outer queries
    using their aliases

Limitations:
  - Only SELECT statements support implicit QB names. DML operations
    (UPDATE, DELETE, INSERT) only support explicit QB names
b30b0f703f7b...
b30b0f703f7b63f0306e68c6c61185856d283684
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
a8a3c2fc865e...
a8a3c2fc865e3bfb6fec3ddac66c9c2cf93ebc16
Eric Herman
Convert comment to compile-time check, fix grammar

By converting the text describing the constraints of the constant
to a compile-time check, this enables us to make IO_SIZE configurable.

It should be noted that this #define is duplicated in the submodule
libmariadb in the include/ma_global.h file.

Signed-off-by: Eric Herman <[email protected]>
9b91138df7b9...
9b91138df7b9c49d1afa50d76c68bcce91d240e3
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
9aa8cf3420fd...
9aa8cf3420fdb019ecf68fbda5cee0367727d300
Aleksey Midenkov
MDEV-38799 Some views are broken in Oracle mode after upgrade to Q1 2026

wrap_select_chain_into_derived() inserts wildcard asterisk over
wrapped SELECT. setup_wild() expands the item wildcard but it does not
update field_translation name which still contains the asterisk. Field
translation was implemented for BUG#5147 to keep view column names
intact, find_field_in_view() uses these field translation names.

Now, the fix uses full field list instead of the wildcard in
wrap_select_chain_into_derived() whenever it is possible.
9466f1d178f6...
9466f1d178f6d3af1af1c300e56bac3c50d3388c
Marko Mäkelä
fixup! 82c788991dd93c7c56cd6247cbf75dfcf9859508
8882f8fe6c5a...
8882f8fe6c5a87e2b367e260627af88ce9130d44
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.
- Converted boolean flags (online, ignore, error_if_not_empty,
mdl_exclusive_after_prepare) from individual boolean
members to bitfields packed in a single byte
- Reduced Alter_inplace_info structure size by 24 bytes
82c788991dd9...
82c788991dd93c7c56cd6247cbf75dfcf9859508
Marko Mäkelä
squash! 998c03acaf9e6407782b09d70fb538994bafdcf8

log_t::attach(): When disabling innodb_log_file_mmap, read checkpoint_buf
from the last file.

log_t::is_mmap_writeable(): A new predicate for detecting PMEM.

log_t::clear_mmap(): Properly restore log_sys.buf.

log_t::WRITE_SIZE_MAX: The maximum log_sys.write_size.

recv_sys_t::find_checkpoint(): When innodb_log_file_mmap=OFF,
restore log_sys.checkpoint_buf from the latest log file.
8132a00c1aa8...
8132a00c1aa8b24167c15c60ed0096d9bdb787f6
Vladislav Vaintroub
DB and table level denies
7d9a4771e982...
7d9a4771e9823f350ca3fd3b9961cd3573adcc48
Eric Herman
Make IO_SIZE compile-time configurable

Making mariadb's IO_SIZE compile-time configurable enables more
straight-forward investigation of the performance implications of having
an IO_SIZE which is different than the memory page size.

The default IO_SIZE of 4096 as defined in include/my_global.h matches
the memory page size of most systems. Larger page sizes are widely
supported, called "huge pages" in Linux, "superpages" in FreeBSD, and
"large pages" in MS Windows.

On POSIX systems, obtaining the page size can be done via:

page_size= sysconf(_SC_PAGESIZE);

On Windows:

SYSTEM_INFO si;
GetSystemInfo(&si);
page_size= si.dwPageSize;

In https://jira.mariadb.org/browse/MDEV-35740 Marko highlights that
there are vastly different uses of IO_SIZE. This "one size fits all"
nature of IO_SIZE is not ideal, future work could split this into
separate constants based upon usage.

See also:
https://github.com/mariadb-corporation/mariadb-connector-c/pull/267

Signed-off-by: Eric Herman <[email protected]>
794e34b81cd8...
794e34b81cd80930be404ccb5091161f8862c342
Monty
Set current_stmt_binlog_format= BINLOG_FORMAT_UNSPEC if binlog is off.

THD::binlog_state is a new variable that simplifies testing if replication
is permanently off, is on or temporarly off (for a sub statement).

Code changes this allows us to do:

One does not need to test for mysql_bin_log.is_open() if one also tests
for thd->is_current_stmt_binlog_format_stmt() or
thd->is_current_stmt_binlog_format_row().

The code also allows the following transformations:

(WSREP(thd) && wsrep_emulate_bin_log) ||
(mysql_bin_log.is_open()) && (thd->variables.option_bits & OPTION_BIN_LOG)
->
thd->binlog_ready()

(WSREP_NNULL(thd) && wsrep_emulate_bin_log) || mysql_bin_log.is_open())
->
thd->binlog_ready_with_wsrep()

(WSREP_EMULATE_BINLOG(thd) || mysql_bin_log.is_open())
->
thd->binlog_ready_with_wsrep()

mysql_bin_log.is_open() && (thd->variables.option_bits & OPTION_BIN_LOG)
->
thd->binlog_ready_no_wsrep()

Other transformation are easy to do by using the bits set in binlog_state
set by decide_binlog_format()

Other things:
- Implement THD::tmp_disable_binlog() and THD::reenable_binlog() using
  the new binlog_state framework.
  Made the functions 'recursive' safe.
  The old code had no effect for row logging, which spider and mroonga
  assumed. Now handler::binlog_log_row() disables row logging properly if
  tmp_disable_binlog() is used
- THD::variables.wsrep_on is now updated by THD:enable_wsrep(),
  THD::disable_wsrep() or THD::set_wsrep(). I added an assert for
  (WSREP_PROVIDER_EXISTS_ && WSREP_ON_) when setting wsrep_on=1
- Ensured that WSREP(thd) is tested before wsrep_thd_is_local() is called.
- Replaced WSREP(thd) with WSREP_NNULL(thd) in all relevant places.

Things to do:
- Remove set_binlog_bit() call and instead set and reset binlog_state
  flag BINLOG_STATE_USER_DISABLED when user changes sql_log_bin value
- We should consider removing OPTION_BIN_LOG and instead use
  binlog_state and BINLOG_STATE_BYPASS. This would allow us to remove
  reset and setting it in decide_binlog_format()
- Update binlog_state with BINLOG_STATE_FILTER only when database or filter
  is changed.  This means we do not have to call binlog_filter->db_ok() for
  every statement.
- Remove clear/reset xxx_binlog_local_stmt_filter() as this is now handled
  by binlog_state.
- Remove 'silent' option from mysql_create_db_internal and instead use
  tmp_disable_binlog() / renenable_binlog()
- Remove testing if binary log is desabled in:
  MYSQL_BIN_LOG::write(Log_event *event_info, my_bool *with_annotate):
    if ((!(option_bin_log_flag)) ||
        (thd->lex->sql_command != SQLCOM_ROLLBACK_TO_SAVEPOINT &&
        thd->lex->sql_command != SQLCOM_SAVEPOINT &&
        !binlog_filter->db_ok(local_db)))
      DBUG_RETURN(0);
- Remove testing of OPTION_BIN_LOG in THD::variables.option_bits as
  this is covered. We may still want to keep the variable in option_bits
  to simplify bug reports. Alternative we could add binlog_state to
  show variables.
- Remove all testing of mysql_bin_log.is_open(). Instead test for
  binlog_ready() in main code and add testing of is_open() when
  trying to commit the binary log.  This is needed as currently
  mysql_bin_log.is_open() is tested without a mutex which makes
  it unreliable.
- Remove testing of WSREP_PROVIDER_EXISTS_ in WSREP_NULL() as this
  is this is guaranteed by THD::enable_wsrep()
6a6f1d1335d2...
6a6f1d1335d244674cb443e603ba5fdc1b7abd7d
Marko Mäkelä
fixup! 1387423e6b2a1fb4daf81e67dac9de6300051ee2
63200915c309...
63200915c30975ab246273ba0aeaf4b8a3ba5980
Thirunarayanan Balathandayuthapani
MDEV-38832 Assertion `!commit_lsn' failed in void trx_t::free()

Problem:
=======
- During drop table, InnoDB fails to remove the table entries
  from InnoDB statistics table when stats_persistent is disabled.
  Later, When we try to do DROP DATABASE, the server removes the stale
  entries from statistics table. 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()

Solution:
========
innodb_drop_database(): Add debug assertion reset to clear
commit_lsn before freeing the transaction.
This also fixes the merge commit 40f708466147a9942121e46965bd7c7006ce4e84
62781aa42d58...
62781aa42d585f5ca886604ab7d00f15693c1dad
Marko Mäkelä
MDEV-38850 Dormant corruption in log_t::clear_mmap()

This is a dormant bug, because the setting innodb_log_file_mmap=ON probably
does not work outside mariadb-backup, because log_t::attach() would refuse
to invoke read-only mmap() on a normal server startup.

This was manually tested in an invocation of
mariadb-backup --prepare --export --innodb-log-file-mmap
which would not write anything to the log file, which
is not intended to be used after the invocation anyway.

log_t::clear_mmap(): Properly copy the last log block
from the memory-mapped buffer, so that it can be used
in subsequent writes to the log.

log_t::WRITE_SIZE_MAX: The maximum log_sys.write_size.
6188cbf0b472...
6188cbf0b472bf8015143b84986d7a7bd44838d0
forkfun
MDEV-38580 TO_DATE should check both formatting and standalone month name

also fixed Serbian locale: Cyrillic was wrongly mapped to Latin
fixed locale.test, that was failing in mtr with --cursor protocol
59181d6125f2...
59181d6125f2b0e9cae2019c873077aa7160baab
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Follow-up to the previous commit to disable the option --sys-triggers by default
551e2348289f...
551e2348289f03766c97e78b622468de889910ea
Vladislav Vaintroub
x
43c05e12751b...
43c05e12751bba5ae32209e914c14cc7e50f5aed
Thirunarayanan Balathandayuthapani
MDEV-38832 Assertion `!commit_lsn' failed in void trx_t::free()

Problem:
=======
- During drop table, InnoDB fails to remove the table entries
from InnoDB statistics table when stats_persistent is disabled.
Later, When we try to do DROP DATABASE, the server removes the stale
entries from statistics table. 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()

Solution:
========
innodb_drop_database(): Add debug assertion reset to clear
commit_lsn before freeing the transaction.
432abe5f6d81...
432abe5f6d81c9e9d17846ac40f48a00b75562e3
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Added the option --sys_triggers for mysqldump to dump
system triggers
Fixed bugs with handling system triggers in statements
SHOW TRIGGERS/SHOW CREATE TRIGGER
424f420908ec...
424f420908ec5a51834f9f245642c95d9f697400
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.
- Converted boolean flags (online, ignore, error_if_not_empty,
mdl_exclusive_after_prepare) from individual boolean
members to bitfields packed in a single byte
- Reduced Alter_inplace_info structure size by 24 bytes
3e9710597578...
3e971059757839981444ada3dc249a55d38e0cf3
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.
3be190ac30c0...
3be190ac30c04f6ca6161dad0e11d145bf75785f
Thirunarayanan Balathandayuthapani
MDEV-38842 Server fails to drop .ibd file when vector table creation fails

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.
Stale file exists 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.
396080e2d032...
396080e2d03201b3762ce31dd69364d6c4ca22e6
Vladislav Vaintroub
x
30ef16d5a5c4...
30ef16d5a5c4cb942642597e811e223be15a8f1d
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
2489d3cf7732...
2489d3cf7732e769ce555107e5f75fd509a868a8
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
1387423e6b2a...
1387423e6b2a1fb4daf81e67dac9de6300051ee2
Marko Mäkelä
fixup! 82c788991dd93c7c56cd6247cbf75dfcf9859508
09657805d04d...
09657805d04dfe6dfe33fb4b3003e06b29c835bd
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.
0034625ae34d...
0034625ae34d76976c894586e5f33f27f6c49eb7
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
00246fa15a71...
00246fa15a7166c890e3b3f3f9efee25c5bb17c9
Monty
Cleanup binary logging API

- Add is_current_stmt_binlog_format_stmt()
- Replace !is_current_stmt_binlog_format_row() with
  is_current_stmt_binlog_format_stmt(). This is in prepartion for using
  BINLOG_FORMAT_UNSPEC if no binary logging.
- Removed printing of temporary_tables info in
  reset_current_stmt_binlog_format_row() as this is not relevant anymore.
- Added testing of (thd->variables.option_bits & OPTION_BIN_LOG) when
  binlogging create procedure.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Wed 18 Feb 2026 09:25:59 (UTC)