Create a Multi-Source Replication test
for these `mariadb-dump --dump-slave` bugs:
* MDEV-7611 (not fixed as of this commit)
* MDEV-5624 (fixed a long time ago)
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
The causes of these test failures are sparatic and haven't been
generated locally. The stack trace looks like it could be an
internal MSAN error too. Disable for the time being as there
is some server coverage of these test paths elsewhere.
If a table had a primary_key index, non_primary_key index,
and an extended index with primary key in desc order,
then the query with where clause predicates containing these
index fields was picking an index_merge plan which was causing
a wrong result.
The plan shouldn't have contained index_merge in the first place,
because the rows produced by one index have rows ordered by rowid
in ascending order, and the rows coming from the other index
were in a different order.
The solution is to not produce index_merge plan in such scenarios.
is_key_scan_ror() would now return false, for non_primary_key indexes
if any primary key part with a reverse sort is present in them.
Issue: When XA transaction is implicitly rolled back, we keep XA state
XA_ACTIVE and set rm_error to ER_LOCK_DEADLOCK. Other than XA command
we don't check for rm_error and DML and query are executed with a new
transaction.
Fix: One way to fix this issue is to set the XA state to XA_ROLLBACK_ONLY
which is checked while opening table open_tables() and ER_XAER_RMFAIL is
returned for any DML or Query.
For all "UNION ALL" queries, the field rows_examined in the
slow query log is always being set to 0. However, this is not
the case with UNION queries although both UNION, and UNION ALL
share the same code.
The problem is that for UNION ALL queries, rows_examined field
in the thd object is not updated to the actual processed rows,
although they are being tracked in the sql_union.cc
Later, when the thd object is used to dump the examined rows
to the slow query log, it was only writing 0, as thd object was
never updated with the processed rows count.
This PR addresses the concern to write rows_examined field correctly
for UNION_ALL queries to the slow query log.
The recursive nature of add_table_function_dependencies
resolution meant that the detection of a stack overrun
would continue to recursively call itself.
Its quite possible that a user SQL could get multiple
ER_STACK_OVERRUN_NEED_MORE errors.
Additionaly the results of the stack overrrun check
result was incorrectly assigned to a table_map result.
Its only because of the "if error" check after
add_table_function_dependencies is called, that would
detected the stack overrun error, prevented a
potential corruped tablemap is from being processed.
Corrected add_table_function_dependencies to stop and
return on the detection of a stack overrun error.
The add_extra_deps call also was true on a stack overrun.
Assertion fails because table is opened by admin_recreate_table():
71 result_code= (thd->open_temporary_tables(table_list) ||
72 mysql_recreate_table(thd, table_list, recreate_info, false));
And that is called because t2 is failed with HA_ADMIN_NOT_IMPLEMENTED:
1093 if (result_code == HA_ADMIN_NOT_IMPLEMENTED && need_repair_or_alter)
1094 {
1095 /*
1096 repair was not implemented and we need to upgrade the table
1097 to a new version so we recreate the table with ALTER TABLE
1098 */
1099 result_code= admin_recreate_table(thd, table, &recreate_info);
1100 }
Actually 'table' is t2 but open_temporary_tables() opens whole list,
i.e. t2 and everything what follows it before first_not_own_table().
Therefore t3 is also opened for t2 processing what is wrong.
The fix opens exactly one specific table for HA_ADMIN_NOT_IMPLEMENTED.
Wrong assertion was added by f1f9284181 (MDEV-34046) because PS
parameter is applicable not only to DELETE HISTORY.
Keeping value of select_lex->where for DELETE HISTORY was remade via
prep_where which is read by reinit_stmt_before_use(). For SELECT
prep_where is set in JOIN::optimize_inner() and that is not called for
DELETE.
`Seconds_Behind_Master` unsets from 0 when a
parallel replica processes an internal event.
Est. 8dad51481b of MDEV-10653, the idle status of the worker
threads directly checks the emptiness of the workers’ queue.
The problem is that the queue could be entirely
internal events that don’t record replicated content.
In contrast, the (main) SQL thread (in both serial and parallel
replicas) uses a state boolean `sql_thread_caught_up` that is
not unset if the event is internal. Therefore, this patch adds
a workers’ equivalent, `worker_threads_caught_up`, that
matches the behaviour of that for the (main) SQL thread.
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Acked-by: Kristian Nielsen <knielsen@knielsen-hq.org>
1. Stricten MDEV-16091’s `rpl.rpl_seconds_behind_master_spike`
to prove that its fix covered MDEV-25999 as well
2. Add a Parallel Replication variant via a new `.combinations` file;
its current failure confirm MDEV-36840.
Because Parallel Replication queues Format Description Events as
position update metaevents, this variant uses a separate set of API-
compatible breakpoints to pause both the main and worker threads.
To support them, this commit replaces the MDEV-33327 patch c75905cacb
with a live-activation solution. In contrast, previous iterations queued
the activation pre-test and relied on other factors to enable the break.
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
It is called from the Replica SQL thread, not IO thread;
and takes a Group Info param, likely once upgraded from the Log Info.
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Since MDEV-31503 fixes ALTER-SEQUENCE might be able to complete its
work including binlogging before a preceding in binlog-order
transaction. There may not be data dependency between the two
transactions, but there would be
"an attempt was made to binlog GTID D-S-XYZ which would create an
out-of-order sequence number"
error in the gtid_strict_mode = ON.
After the preceding transaction started committing, and does it rather
slow, ALTER-SEQUNCE was able to find a time window to complete because
it temporarily releases its link with the waitee parent transaction.
And while having it released it also erroneously executes the binlogging part.
Fixed with restoring the commit dependency on the parent before
ALTER-SEQUNCE takes on binlogging.
main.json_debug_nonembedded_noasan fails because of stack
overrun on Debug + MSAN testing.
Since MDEV-33209 (09ea2dc788)
the the stack overflow errors are just injected instead of
frailer mechanisms to consume stack. These mechanims where
not carried forward to the JSON_TABLE functions where
the pattern was the same.
Related MDEV-34099 (cf1c381bb8) makes check_stack_overrun never fail
under Address Sanitizer (only).
The previous ALLOCATE_MEM_ON_STACK did in MemorySanitizer consume
memory, but check_stack_overrun did fail because its 16000 byte
safety margin was exceeded. The allocation of the 448 byte error
ER_STACK_OVERRUN_NEED_MORE is well within these bounds, however
under the safemalloc implementation, "backtrace" library call is called,
which does further allocation for every stack frame. This exceeds the stack.
Fixes:
JSON_TABLE functions that trigger on out of memory debug instrumentation
replaced with the mechanism from MDEV-33209.
The get_disallowed_table_deps_for_list in a non-Debug build returned
incorrectly 1, instead of -1 indicating the out of memory condition.
In json_table add_extra_deps never passed the out of memory error
condition to the caller and would continue to run in a loop, potentially
recursively under these near out of stack conditions.
The Memory, Undefined Behaviour, Address and Thread sanitizers provide
sufficient instrumentation and a backtrace so the safemalloc
functionality provides insufficent value with these. As such is
disabled under WITH_SAFEMALLOC=AUTO.
With all of thse corrected the main.json_debug_nonembedded_noasan no
longer needs its ASAN exclusion.
The JSON_TABLE tests in this test case was dropped in a merge from 10.6
so these tests are re-added.
`rpl.rpl_semi_sync_master_disable_with_slave` from MDEV-36359 expected
the primary to be at the control state when the replica syncs up.
However, this timing is not guaranteed.
In consequence, the test would occasionally fail with
the primary at an incorrect (likely the previous) state.
This patch overcomes this by replacing the state assertion with a wait.
While there, the patch also escapes the `_`s in the LIKE operand.
Co-authored-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Add port information to server socket creation log message to improve
clarity when multiple ports are in use (e.g., default port 3306 and
extra_port). Previously, the message only showed "Server socket created
on IP: '[IP]'" without port information, making it ambiguous. The
modified message now includes the port number: "Server socket created on
IP: '[IP]', port: '[PORT]'".
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Reimplement test for MDEV-28567 such that it behaves consistently and
consistently covers the code that it was intended to cover. The test
itself moved to mdl_sync.test, because lock_sync.test is supposed for
testing THR_LOCK, not MDL. Verified with DBUG_ASSERT(0) in
open_tables() (from 92bfc0e8c4) restored.
The test is failing with various symptoms as it was designed to be
sporadic. It did cover the code that it was supposed to cover in
less than 0.1% of runs. That is the following command succeeds often
with DBUG_ASSERT(0) in open_tables() (from 92bfc0e8c4) restored:
./mtr --repeat=25 --parallel=40 lock_sync{,,,,}{,,,,}
Test is also reimplemented such that it doesn't rely on buggy "MDL
overweight" behaviour as described in MDEV-36887. Previously it did
require preceding statements that fall in deadlock in default
connection. Now it works consistently in both cases: if there was
preceding deadlock and if there was none.
mdl_after_find_deadlock sync point added to avoid premature deadlock
handling by connections that don't intend to handle it. ALTER VIEW
connection is supposed to handle it, this makes test behaviour
consistent.
Tracking history:
92bfc0e8c4 MDEV-17554, assert added
f88511647a MDEV-28567, test added, assertion modified
fe3adde250 MDEV-29060, test moved, fix attempted
8ee93b9cb4 MDEV-29060, fix attempted
611d442510 fix attempted
77c465d5aa assertion modified
4c695c85bd assertion removed
MDEV-29474 - subj
MDEV-36665 - duplicate of MDEV-29474
When REPAIRing a CSV table, the CSV engine marks the table as having
no rows in the case that there are rows only in memory but not yet
written to disk. In this case, there's actually nothing to repair,
since nothing exists on disk; make REPAIR idempotent for CSV tables.
The sequence that causes the issue:
1. file->row_logging is false because slave-bin was not open;
2. TABLE::mark_columns_per_binlog_row_image() didn't mark column for
read because file->row_logginbg is false. This was implemented in
e53ad95b73 (MDEV-6877);
3. TABLE::update_virtual_fields() didn't update virtual field value
because column is not marked for read;
4. calc_row_difference() sees o_len as UNIV_SQL_NULL, but new row
value is "1". The virtual column is added to update vector;
5. row_upd() tries to update secondary index, but row_upd_sec_step()
doesn't see old value in the index.
The patch does mark_virtual_column_with_deps() via
column_bitmaps_signal() in case of rgi_slave in
mark_columns_per_binlog_row_image() so that non-stored virtual columns
are marked for update in slave thread.
Also fixed column_bitmaps_signal() for partitioning where the signal
did not reach the partition storage engine.
Problem:
Empty queries are incremented if no rows are sent to the client in the
EXECUTE phase of select query. With cursor protocol, rows are not sent
during EXECUTE phase; they are sent later in FETCH phase. Hence,
queries executed with cursor protocol are always falsely treated as
empty in EXECUTE phase.
Fix:
For cursor protocol, empty queries are now counted during the FETCH
phase. This ensures counter correctly reflects whether any rows were
actually sent to the client.
Tests included in `mysql-test/main/show.test`.
Log tables cannot work with transactional InnoDB or Aria, that is
checked by ALTER TABLE for ER_UNSUPORTED_LOG_ENGINE. But it was
possible to circumvent this check with CREATE TABLE. The patch makes
the check of supported engine common for ALTER TABLE and CREATE TABLE.
It was mysql_install_db, and this is changed to mariadb-install-db.
likewise changed all of the support-files references to
mysql_install_db.
This install script is part of the service as a useful instigation
step, and a no-op in subseqeuent runs.
This script does however change the auth_pam_tool_dir ownership.
When running a multi-instance based on username, changing the
auth_pam_tool_dir will only cause troubles for the other users.
If you are running multiple instances on username is seems you
are unlikely do be having pam access for all users. Even
if you where the solution on auth_pam_tool_dir would be a group
permission and group access based on the users.
As such skip the changing of ownership.
A deadlock forces the on going transaction to rollback implicitly.
Within a transaction block, started with START TRANSACTION / BEGIN,
implicit rollback doesn't reset OPTION_BEGIN flag. It results in a
new implicit transaction to start when the next statement is executed.
This behaviour is unexpected and should be fixed. However, we should
note that there is no issue with rollback.
We fix the issue to keep the behaviour of implicit rollback (deadlock)
similar to explicit COMMIT and ROLLBACK i.e. the next statement after
deadlock error is not going to start a transaction block implicitly
unless autocommit is set to zero.
This controls which linux implementation to use for
innodb_use_native_aio=ON.
innodb_linux_aio=auto is equivalent to innodb_linux_aio=io_uring when
it is available, and falling back to innodb_linux_aio=aio when not.
Debian packaging is no longer aio exclusive or uring, so
for those older Debian or Ubuntu releases, its a remove_uring directive.
For more recent releases, add mandatory liburing for consistent packaging.
WITH_LIBAIO is now an independent option from WITH_URING.
LINUX_NATIVE_AIO preprocessor constant is renamed to HAVE_LIBAIO,
analogous to existing HAVE_URING.
tpool::is_aio_supported(): A common feature check.
is_linux_native_aio_supported(): Remove. This had originally been added in
mysql/mysql-server@0da310b69d in 2012
to fix an issue where io_submit() on CentOS 5.5 would return EINVAL
for a /tmp/#sql*.ibd file associated with CREATE TEMPORARY TABLE.
But, starting with commit 2e814d4702 InnoDB
temporary tables will be written to innodb_temp_data_file_path.
The 2012 commit said that the error could occur on "old kernels".
Any GNU/Linux distribution that we currently support should be based
on a newer Linux kernel; for example, Red Hat Enterprise Linux 7
was released in 2014.
tpool::create_linux_aio(): Wraps the Linux implementations:
create_libaio() and create_liburing(), each defined in separate
compilation units (aio_linux.cc, aio_libaio.cc, aio_liburing.cc).
The CMake definitions are simplified using target_sources() and
target_compile_definitions(), all available since CMake 2.8.12.
With this change, there is no need to include ${CMAKE_SOURCE_DIR}/tpool
or add TPOOL_DEFINES flags anymore, target_link_libraries(lib tpool)
does all that.
This is joint work with Daniel Black and Vladislav Vaintroub.
In a UBSAN debug build, the comparisons with next_mrec_end are made
with index->online_log's head/tail members' block ptr with a sort buffer
size offset (1048576).
The logic that flows though to this point means that even srv_sort_buf_size
above a null pointer wouldn't contain the value of next_mrec_end.
As such this is a UBSAN type fix where we first check if the
head.block / tail.block is null before doing the asserts around
this debug condition. This would be required for the assertions
conditions not to segfault anyway.
log_hdr_buf: Align to an 8-byte boundary, because we will actually
assume at least 4-byte alignment in log_crypt_write_header().
This fixes a regression that had been introduced in
commit 685d958e38 (MDEV-14425)
where a 512-byte alignment requirement was relaxed too much.
Problem:
=========
(1) Mariabackup tries to read the history data from
mysql.mariadb_backup_history and fails with segfault. Reason is that
mariabackup does force innodb_log_checkpoint_now from commit 652f33e0a44661d6093993d49d3e83d770904413(MDEV-30000).
Mariabackup sends the "innodb_log_checkpoint_now=1" query to server and
reads the result set for the query later in the code because the query
may trigger the page thread to flush the pages. But before reading the
query result for innodb_log_checkpoint_now=1, mariabackup does execute
the select query for the history table (mysql.mariadb_backup_history)
and wrongly reads the query result of innodb_log_checkpoint_now. This leads
to assertion in mariabackup.
(2) The recording of incremental backups has the format as "tar"
when mbstream was used. The xb_stream_fmt_t only had XB_STREAM_FMT_NONE
and XB_STREAM_FMT_XBSTREAM and hence in the mysql.mariadb_backup_history
table the format was recorded as "tar" for the "mbstream" due to the
offset in the xb_stream_name array within mariadb-backup.
(3) Also under Windows the full path of mariabackup was recorded in the the
history.
(4) select_incremental_lsn_from_history(): Name of the backup and UUID
of the history record variable could lead to buffer overflow while
copying the variable value from global variable.
Solution:
=========
(1) Move the reading of history data from mysql.mariadb_backup_history
after reading the result of innodb_log_checkpoint_now=1 query
(2) We've removed the "tar" element from the xb_stream_name. As the
"xbstream" was never used, the format name is changed to mbstream.
As the table needs alteration the "mbstream" appended instead of
the unused xbstream in the table. "tar" is left in the enum as
the previous recordings are still possible.
(3) The Windows path separator is used to store just the executable
name as the tool in the mariadb_backup_history table.
(4) select_incremental_lsn_from_history(): Check and validate
the length of incremental history name and incremental history uuid
before copying into temporary buffer
Thanks to Daniel black for contributing the code for solution (2) and (3)
There was a Wrong result due to Table Elimination
when 'unique_col IS NULL' condition is supplied in the left-join query.
An index on an unique_col was created for the table, and it
is being used in the plan.
As the query was a left join, no fields from the right table were
projected. The right table was getting wrongly eliminated although
multiple rows from the right could be matched to a single row from the
left with the condition `unique_col IS NULL'.
This PR addresses the problem by including an additional check before
eliminating a table in check_equality() function of opt_table_elimination.cc
innodb.doublewrite: Skip the test case if we get an unexpected
checkpoint. This could happen because page cleaner thread
could be active after reading the initial checkpoint information.
MSAN has been updated since 2022 when this macro was added
and as such the working around MSAN's deficient understanding
of the fstat/stat syscall behaviour at the time is no longer
required.
As an effective no-op a straight removal is sufficient.
Problem:
=======
- InnoDB unpoisons the freed page memory to make sure that
no other thread uses this freed page. In buf_pool_t::close(),
InnoDB unmap() the buffer pool memory during shutdown or it
encountered during startup. Later at some point, server
re-uses the same virtual address using mmap() and writes into
memory region. This leads to use_after_poison error.
This issue doesn't happen in latest clang and gcc version.
Older version of clang and gcc can still fail with this error.
ASAN should unpoison the memory while reusing the same virtual
address. This issue was already raised in
https://github.com/google/sanitizers/issues/1705
Fix:
===
In order to avoid this failure, let's unpoison the buffer
pool memory explictly during buf_pool_t::close() for
lesser than gcc-14 and clang-18 version.
Backing up with mariabackup a datadir containing
ENGINE=Mroonga tables leaves behind the corresponding
*.mrn* files. Those tables are therefore broken once
such backup is restored.
minor style/mtr changes by Daniel Black
Hurd doesn't have the mechanism to identify the user connecting to
a socket via a system call as MDEV-8535 highlighted. As such it
can't be supported so we disable it in Debian's mysql_release profile.
Hurd string from uname -m, "SYSTEM processor: i686-AT386" in mariadb
output. And wiki reference https://en.wikipedia.org/wiki/Uname
Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006531
CHECK constraint uses caching items and the value is cached even in
case of error. At the second execution the cached value is taken and
the error is not thrown. The fix does not cache value in case error
was thrown during value retrieval.
This issue arises when we have an outer reference resolved in another outer reference
where that outer reference is resolved in a outer select that is a grouping select.
Under these circumstances, the intermediate item is wrapped in an Item_outer_ref and
fixing is deferred later until fix_inner_refs. As this item wrapper isn't fixed
we fail this assertion. The fix here is to resolve the item at the lowest level
to the item inside the wrapper, which is fixed. This item can then get it's
own wrapper pointing to the ultimate resolution of this item.
Approved by Sanja Byelkin (sanja@mariadb.com) 2025-06-13
Now that RocksDB has been synced up to 6.29 which includes the changes
mentioned in the CMake comment support for building on non-Linux aarch64
OSes can be enabled.
replication problems
DELETE HISTORY did not process parameterized PS properly as the
history expression was checked on prepare stage when the parameters
was not yet substituted. In that case check_units() succeeded as there
is no invalid type: Item_param has type_handler_null which is
inherited from string type and this is valid type for history
expression. The warning was thrown when the expression was evaluated
for comparison on delete execution (when the parameter was already
substituted).
The fix postpones check_units() until the first PS execution. We have
to postpone where conditions processing until the first execution and
update select_lex.where on every execution as it is reset to the state
after prepare.
Nullability is decided in two stages-
1. Based on argument NULL-ness
Problem:
- COALESCE currently uses a generic logic- "Result of a function
is nullable if any of the arguments is nullable", which is wrong.
- IFNULL sets nullability using second argument alone, which incorrectly
sets the result to NULL even when first argument is not null.
Fix:
- Result of COALESCE and IFNULL is set to NULL only if all arguments are
NULL.
2. Based on type conversion safety of fallback value
Problem:
- The generic `Item_hybrid_func_fix_attributes` logic would mark the
function's result as nullable if any argument involved a type
conversion that could yield NULL.
Fix:
- For COALESCE and IFNULL, nullability is set to NOT NULL if the first
non-null argument can be safely converted to function's target return
type.
- For other functions, if any argument's conversion to target type could
result in NULL, the function is marked nullable.
Tests included in `mysql-test/main/func_hybrid_type.test`
Fix AWS SDK build, it has changed substantionally since the plugin was
introduced. There is now a bunch of intermediate C libraries, aws-cpp-crt
and others, and for static linking, the link dependency must be declared.
Also support AWS C++ SDK in vcpkg package manager.
