Console View

Categories: connectors experimental galera main

Legend:

Passed

Failed

Warnings

Failed Again

Running

Exception

Offline

No data

connectors

experimental

galera

main

f94cebca62a6...

f94cebca62a649a21abe137b630a14d85a16377d

Marko Mäkelä

marko.makela@mariadb.com

fixup! be167af0e47564318af5b07eabcd185a2d7906bb

f49e838d367f...

f49e838d367f2154b3edb43effa99ff9eb0d8602

DerZc

34330257+DerZc@users.noreply.github.com

MDEV-40689 Wrong result: BIT_AND/BIT_OR/BIT_XOR in WINDOW functions over a frame containing NULL

BIT_AND, BIT_OR, and BIT_XOR window functions can return incorrect
values as a sliding frame moves past NULL input rows.

Adding a NULL argument leaves the bit-aggregate state unchanged, but
removing that row unconditionally calls remove_as_window() with
val_int()'s value. The removal path therefore changes state for a row
that never contributed to the aggregate.

Evaluate the departing window argument once and retain its unsigned
value. Call remove_as_window() only when the evaluated argument is
non-NULL. Leave the existing incremental window algorithm and non-window
aggregation path in place.

The regression checks all three bit aggregates over ROWS BETWEEN 1
PRECEDING AND CURRENT ROW with interleaved NULL and non-NULL values,
including removal of a real zero and restoration of the neutral values
after the frame becomes all-NULL.

Bug report: https://jira.mariadb.org/browse/MDEV-40689

f21444cd039e...

f21444cd039ebb07c5442082c1906b0e37ba7cbd

Sergei Golubchik

serg@mariadb.org

Merge branch '11.4' into 11.8

ecda07c65644...

ecda07c6564488ba0c807dcbdcfa3bea4b486ed9

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-41211 Remove unused index_read_idx() from both Federated engines

ha_federated::index_read_idx() and ha_federatedx::index_read_idx()
have no callers and do not override a handler method. Remove them,
and remove the sentence in the comment on each index_read() that says
index_read() calls it. Comments that describe index_read_idx() now
name index_read() or index_read_idx_map(), whichever does that read.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

e47670210df0...

e47670210df01f9f7cf91984c79714bbf6fa89b7

Marko Mäkelä

marko.makela@mariadb.com

Add my_open_dir(), my_win_open() and improved my_copy()

This is based on commit 059bf8f1ba5aa7bb2fdebc42833c20b5d162b16a by Monty.

- Improved my_copy() using copy_file_range and mmap
- Improve performance of my_win_open() by taking free entries from a list
instead of searching after a free space in an array.

New mysys copy functions:

int my_copy_file(File from, File to, myf MyFlags);
int my_copy_file_range(File from, File to, my_off_t start,
my_off_t end, myf MyFlags);

Added compatibility functions for easy converting a windows HANDLE to
a File and back:

File my_convert_handle_to_file(my_native_file handle, int oflag);
void my_detach_file(File fd);
which complements the existing my_native_file_handle(fd)

New functions for looping over files in a directory:

MY_NO_CACHE_DIR *my_dir_open();
int my_dir_read_next()

ce029f6148fc...

ce029f6148fc05c477741aa4585edc8432feafc9

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-41303: rand() in a semi-join subquery is checked on outer rows

Do not merge a subquery into its parent as a semi-join when it has
the UNCACHEABLE_RAND flag, which RAND() and ROWNUM set. Derived
tables already follow this rule. ROWNUM sets the same flag, so this
patch replaces the check for ROWNUM with a check for UNCACHEABLE_RAND.

Previously, converting an IN subquery to a semi-join moved its WHERE
into the parent WHERE. A condition there such as rand(1) < 0.09
doesn't rely on any columns, so it is attached to the last table of
the join order that is outside any materialized semi-join. With
SJ-Materialization it was checked once for each outer row instead of
once for each row of the subquery, and the query returned a wrong
count.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

be167af0e475...

be167af0e47564318af5b07eabcd185a2d7906bb

Marko Mäkelä

marko.makela@mariadb.com

Replace backup_phase with extended backup_stages

This is based on a commit 281a0c99986824784a66659f2332db3ec362846f
by Monty.

According to Monty, this:
- Galera should now be supported (needs testing)
- Enables ddl logging (so we can use it in the future)
- Flushes binary logs (we still must add code to copy them)
- mdl locks are consistent between mariadb-backup and backup command
- Give errors if backup command is done under a transaction, global
read lock or lock tables.
- Retry for MDL_BACKUP_WAIT_DDL (needed for
backup.backup_ddl_concurrent_verify)

Things to do (in addition to the things in my earlier review) :
- At backup_stage stage start, force rotate of aria log files. This
allows us to copy all old logs without any locks
- Copy all transactional tables and old aria logs under BACKUP_START (as
- maria-backup does)
- Copy the active aria log file under block commit (Only one file as aria
log rotation is disabled while backup is running.
- Improve speed of copying aria tables by copy files in up to 1M
blocks and run checksum on the blocks and only re-read blocks with
- wrong checksum.
- Copy non transactional files under BACKUP_START.

b6398296aeee...

b6398296aeeeb253bdb3d1dd1620d2bb03836bf7

Khaled Riyad

khaled57.dev@gmail.com

MDEV-38861 heap-use-after-free in Prepared_statement::execute()

DROP PROCEDURE and CREATE OR REPLACE PROCEDURE executed from inside the
routine itself removed it from the SP cache. sp_head::destroy() then freed
the memory root that the running sp_head, its LEX and its instructions
live in, and the caller kept using them.

Skip the removal while the routine is being executed. sp_cache_invalidate()
above has already bumped the cache version, so the stale entry is removed by
the next lookup, after IS_INVOKED has been cleared.

b51d2f12bc27...

b51d2f12bc27a29897caf8cb982077683fe47fcd

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-41211 Federated multi-table DELETE keeps a const table row

A multi-table DELETE on a FEDERATED or FederatedX table went wrong
when a primary key lookup made the target a const table. The
optimizer reads a const table's row through index_read_idx_map(),
whose default implementation ends the index scan and frees the result
set. The server asks for the row's position later, during execution,
so the saved position was empty. FederatedX skipped the row and
FEDERATED crashed in rnd_pos().

Both engines now override index_read_idx_map() so that the lookup
leaves its result set open, as index_read() does. position() then
records a valid position, and the result set is freed at the end of
the statement. FEDERATED's reset() now also clears stored_result,
which otherwise pointed at a freed result set and was freed again
when the table was closed.

Tests include a multitable UPDATE with a const target, which crashed
both engines before the fix.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

ab6101e91c04...

ab6101e91c04d814818a09b24b8ca79ad8d3e677

Marko Mäkelä

marko.makela@mariadb.com

Use the new my_dir() and my_copy() interfaces in backup

Based on commit fdaa4fd8a2ad43960bab7fb8084f3c00a179975e

a6cef7a9cc61...

a6cef7a9cc6139f7eea2fc2ee423bedfc88136fa

sjaakola

seppo.jaakola@mariadb.com

MDEV-38243 Tests for nested and self-referencing FK cascades

This is a patch posted by Marek Stipek's review, with following comment:

The row images of a reported cascade action lived in two plain THD
members, on the assumption that at most one cascade action is in flight
per THD. InnoDB performs the next level of an FK chain from inside the
outer cascade action, though (row_update_cascade_for_mysql() recurses
into row_ins_foreign_check_on_constraint()). For a chain like
gp -> p -> c:

- the nested action for c overwrote the before-image captured for p,
reported c and freed the images, so thd_fk_cascade_row() for p found
no image and silently dropped the row. Only the deepest level reached
the binary log, and since its events carry FK_CASCADE_EVENTS_F the
replica did not re-run the cascade either: it kept the rows of p,
silently diverging from the primary;
- the nested capture reused the buffer allocated for p's row length, so
a child with a longer row than its parent overran it (debug builds
report "Freeing overrun buffer" and crash).

Keep the images on a stack instead: capturing a before-image opens a
frame with buffers sized for its own table, and thd_fk_cascade_row() or
thd_fk_cascade_abort() closes it. InnoDB now closes the frame also when
capturing the before-image failed, as the service contract already
asked for, so every frame is closed exactly once.

Self-referencing foreign keys: the child of such a cascade is the table
the statement itself changes, through the instance of it opened for the
foreign key. That handler has not read anything, so it has no row
template yet, and ha_innobase::fk_cascade_fetch_row() refused to convert
the row, although it rebuilds the template anyway, allocating it if
needed. The cascaded rows were not logged; when the statement also
cascaded into another table, whose rows were, the replica did not re-run
the cascade either and kept the self-referencing rows. Drop the check.

The same check made capture fail on a replica, for the handler of the
child opened for the foreign key there has not read anything either: the
pull request documents the feature as inert on the applier and pins it
in rpl_fk_cascade_binlog_row_slave_option, but the child is open via FK
prelocking there too. With the check gone, a replica with the feature
ON (origin OFF) captures the cascades it re-runs and logs them in its own
binary log, as any other session does; the test and the design document
now say so.

Order of the cascaded rows: the queue was emitted at statement end, after
all rows of the statement itself. When a cascade changes a row that the
statement changes after it - with the self-referencing cascades now
captured, e.g. DELETE FROM s WHERE id IN (1,2) with s.parent_id -> s.id
ON DELETE SET NULL - the binlog had DELETE 2 before the cascaded UPDATE
of 2, and the replica stopped with ERROR 1032. handler::binlog_log_row()
now emits the queue before each row of the statement is logged: the
cascades that row change ran precede it, as they did in execution.
Derived rows and the statement's own go to separate row events, so that
FK_CASCADE_DERIVED_F keeps marking exactly the derived ones.

- rpl_fk_cascade_binlog_row_mixed_eligibility: a statement with an
ineligible child table is not captured at all (an eligible and an
ineligible sibling, an ineligible grandchild, an all-eligible control
case), checked on the replica and in the binlog. The design document
refers to it, but it is not in the pull request.
- rpl_fk_cascade_binlog_row_multilevel: cascades through several levels
up to the InnoDB maximum of 14 below the parent, and one level deeper
(the statement fails, nothing is logged); UPDATE and SET NULL chains,
a diamond, savepoints, self-referencing foreign keys with and without
another child, and the order of the cascaded rows relative to the
statement's own. Each case is checked on the replica.
- galera_fk_cascade_binlog_events, ..._log_bin: the same in Galera,
without and with a binary log, with parallel applying.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

9c3ae2b2b562...

9c3ae2b2b5623f2ca8c24c418922ea904afe04d9

Georgi (Joro) Kodinov

joro@mariadb.org

more doxygen formatting added.

9647fd4b88c6...

9647fd4b88c67b949d1de1fdf16f40d29270e69a

bsrikanth-mariadb

srikanth.bondalapati@mariadb.com

MDEV-40598: Capture sequences used only in column DEFAULT expressions

Problem:
A sequence referenced only in a column's DEFAULT expression (e.g.
"a INT DEFAULT NEXTVAL(s1)") is opened only when a statement
evaluates DEFAULT values (INSERT, LOAD DATA, etc). A plain SELECT
never opens it, so the sequence never appears in
thd->lex->query_tables, and Optimizer_context_recorder::
dump_sql_script() had no way to see it. The dependent table's
definition was then captured without the sequence it depends on,
making the captured context unusable on replay.

TABLE::internal_tables lists these sequences, but its entries'
TABLE_LIST::table pointer is set by open_table() and never reset when
the statement ends, so it can point to a TABLE that has since been
closed, reused or freed. It cannot be trusted as "open now".

Fix:
dump_sql_script() walks TABLE::internal_tables for each dumped table
and calls the new resolve_default_sequence() for each entry. That
function never reads the cached TABLE_LIST::table; it uses only the
entry's db and table name to resolve the sequence independently,
skipping sequences that were already dumped:

- Fast path: if the sequence is in thd->open_tables and was used by
this statement (TABLE::query_id match, which matters under LOCK
TABLES), dump its CREATE SEQUENCE and current value, as for a
sequence used directly in the query.
- Slow path: otherwise open it in an isolated LEX, statement arena
and Open_tables_state (arena swap as in
fill_schema_table_by_open(), the rest as in
Table_ident::resolve_table_rowtype_ref()), so the running
statement's LEX, sroutines list, locks and a prepared statement's
permanent arena are not disturbed. The MDL request is non-blocking
when the thread already holds locks. As the statement never used
the sequence, the user's SELECT privilege on it is checked first.
Only the CREATE SEQUENCE is dumped, never SETVAL. If the sequence
cannot be opened, is not accessible, or the name no longer
resolves to a sequence (it was dropped, replaced by a view, ...),
the new warning ER_OPT_CONTEXT_SEQUENCE_CAPTURE_FAILED is pushed,
in addition to the underlying error turned into a warning, and
nothing is captured for it. A kill is left as an error, and OOM
makes the capture fail.

To share code with the existing dump loop, the "register the name in
the dedup hash and emit CREATE DATABASE" step is factored out into
register_table_for_dump(), and the SETVAL logic of the loop into
dump_sequence_current_value(). Sequences are dumped before the
dependent table's CREATE TABLE, so replay can recreate both in order.

Tests (opt_context_store_ddls.test): INSERT-opened sequence; plain
SELECT; LOCK TABLES with the sequence locked but not used (no
SETVAL); a user without privilege on the sequence; two sequences in
one table; dropped sequence (warning, table still captured); stored
function in the query (separate LEX); name replaced by a view; and
re-execution as a prepared statement.

94a62664bd71...

94a62664bd7136987aefe3c80a020c0f9cd30eb2

Rucha Deodhar

rucha.deodhar@mariadb.com

MDEV-41181: ASAN heap-buffer-overflow after SELECT JSON_SCHEMA_VALID

8f3cadfb8e39...

8f3cadfb8e39f303c9401f6cfbf2573acca55b7a

Georg Richter

georg@mariadb.com

MDEV-40146 vio_gencert function doesn't set serial number

this apparently breaks RFC 5280, and makes python cryptography module
unhappy.

8dddd70215a6...

8dddd70215a68e26117178f730751a2e141ab9f8

drrtuy

drrtuy@gmail.com

MDEV-40957 MTR tests to cover DML statements in a replicated setup.

89c239b72f40...

89c239b72f40d8a2025c30cb52a8cbca99bb54e5

sjaakola

seppo.jaakola@mariadb.com

MDEV-38243 Write binlog row events for changes done by cascading FK operations

1. Overview
This commit implements a feature which changes the handling of cascading foreign
key operations to write the changes of cascading operations into binlog.
The applying of such transaction, in the slave node, will apply just the binlog
events, and does not execute the actual foreign key cascade operation.

Having cascaded FK changes in binlog simplifies the slave side applying and makes
it more predictable in terms of potential interference with other parallel applying
happening in the node.

This feature can be turned ON/OFF by new variable:
rpl_use_binlog_events_for_fk_cascade, with default value OFF

2. Design

The engine reports cascade actions through a new generic service,
include/mysql/service_thd_fk_cascade.h, and carries no binlog knowledge of its
own. It asks whether the server wants to be notified of cascade FK, lets the
server capture the before and after row images at the points where cursor is
positioned, and reports the completed action. The server owns the row
images, the column bitmaps that define them, and every decision about what is
done with them. The engine's only contribution is handler::fk_cascade_fetch_row(),
implemented by ha_innobase, which converts the record the cascade cursor sits on
into MySQL row format.

Server side, the reported rows are queued on the THD in execution order and
written to the binary log at statement end or commit, after the originating
statement's own events; they are discarded on rollback and on rollback to
savepoint. Logging them inline would place every cascade delete ahead of every
deferred update within a statement.

The cascaded FK binlog events have new event flag: FK_CASCADE_EVENTS_F, which
tells the slave applier to skip FK cascading.
Binlog events have also flags to mark both original and derived (cascaded FK) events.
This will make it possible for the slave to autonomously choose whether to use
the derived events in applying or to execute the cascade operation.

Binlogged cascade FK events are also correctly handled in slaves with old MariaDB
version. This is because the events logged in cascade operation are additionally
flagged with the NO_FOREIGN_KEY_CHECKS_F flag, so replica that does not understand
the new FK_CASCADE_EVENTS_F flag, still disables foreign key checks in applying
and does not re-execute the cascade

Conplete design is presented in a design document MDEV-38243-design.md, which can
be removed if PR is merged.

3. Trigger support
The SE/server API delegates the actual work to be done in server side. SE (innodb)
has to call 4 handler functions and prepare row images for the arguments.
With this API, server is notified of cascade FK action to happen, and can react
accordingly.

This commit has implemented the binlogging of cascade FK actions, but
there are two other possible uses as well:
- checking FK constraints after FK child table delete
- calling trigger for the child table delete/update

In the design, these handlers are called consumers.

For supporting triggers, it turned out that BEFORE row type of triggers are
too hard to support. This is because the the handler is called from inside
innodb, having a number of innodb resouces locked and execution residing
inside a innodb mtr. Note that the cascade operation may dive deeper in the
FK constraint chain, and callig BEFORE row trigger would require all this
work to be rolled back to isolate innodb for the trigger call.

AFTER row type of triggers, otoh can be supported with this API. For these,
the trigger call requests can be queued and called after the statement execution
is complete.

4. Testing

The commit has mtr tests for testing the feature:

rpl.rpl_fk_cascade_binlog_row - feature OFF vs ON
rpl.rpl_fk_cascade_binlog_row_ordering - event ordering
rpl.rpl_fk_cascade_binlog_row_rollback - discard on rollback
rpl.rpl_fk_set_null_binlog_row - SET NULL capture
rpl.rpl_fk_cascade_binlog_row_slave_option - origin OFF / replica ON
rpl.rpl_fk_cascade_binlog_row_old_slave - old-replica compatibility
rpl.rpl_fk_cascade_binlog_row_mixed_eligibility - mixed child eligibility

7b9f19a6aafb...

7b9f19a6aafbefff12f595539a4336f8d963264a

Georgi (Joro) Kodinov

joro@mariadb.org

more doxygen formatting added.

6f8a8ed49ad3...

6f8a8ed49ad3ae5a375943ca29bc9b166a3bf8fa

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-31180: MyISAMMRG Crash on UPDATE of an updateable VIEW

Attach the children of a MERGE table once per statement, and keep the
value of pos_in_table_list for a MERGE table on subsequent executions
of a prepared statement.

6d35ae303ae4...

6d35ae303ae4082d2f3507d6d1280679b99ec128

Mohammad Tafzeel Shams

tafzeel.shams@mariadb.com

MDEV-41242 : Fix resource leaks on InnoDB/mariabackup error paths found by Infer

Several error-handling paths returned without releasing a resource
already acquired earlier in the function, or checked the wrong handle
entirely, risking use of an unopened handle.

Changes:
- SysTablespace::read_lsn_and_check_flags(): close the datafile handle
on header-validation failure.
- xb_process_datadir(): check the freshly opened `dir` handle instead
of the stale `dbdir`, fixing a handle leak and a possible use of an
unopened directory handle.
- wsrep.cc / xb_load_list_file(): close file handles before die(), and
null-check fopen() results in wsrep.cc.
- datadir_iter_new(): free datadir_path and destroy the mutex on the
os_file_opendir() failure path.

64929e06781b...

64929e06781b69f79e243a57a0cee7b291f0753f

Brad Smith

brad@comstyle.com

crc32c: check elf_aux_info() return value in ppc64 probe

elf_aux_info(3) leaves the output buffer unmodified on failure, so
ignoring the return value could test an uninitialized cpufeatures and
wrongly enable the POWER8 vector-crypto path.

Treat failure as "no features" so the probe falls back to the generic
implementation.

643b04344551...

643b0434455132b78979308d44004efdaf2e4bb6

Thirunarayanan Balathandayuthapani

thiru@mariadb.com

MDEV-32067 InnoDB linear read-ahead had better be logical

The traditional linear read-ahead, enabled by
innodb_read_ahead_threshold, only helps when consecutively
accessed pages have adjacent page numbers.

That is rarely true for B-tree leaf pages: after splits,
merges and page reuse, the logical order of leaves has
nothing to do with their physical page numbers. So for a
scan of scattered leaves the old read-ahead either did nothing
or read the wrong pages.

This replaces linear read-ahead of index pages with a logical
read-ahead that prefetches the actual leaf pages a scan is
going to visit, discovered from the B-tree during traversal.
After this change, the exact nonzero value of
innodb_read_ahead_threshold matters only for the read-ahead of undo
log pages.

buf_read_ahead_undo(): Renamed from buf_read_ahead_linear(). Now
invoked only for undo log pages, whose page numbers are
sequential. It is no longer called on BLOB pages or index pages.

buf_read_ahead_one(): Read ahead a single leaf page.

buf_read_ahead_pages(): Read ahead a set of known B-tree leaf pages.
Stops at the first page that is already resident or fails.

buf_read_ahead_random(): Split into a decision part(which extent
to read) and action part (issue the reads)

The pending read throttle now compares the
os_aio_pending_reads_approx() with buf_pool.curr_size() instead of
current pool bytes, which had made the throttle a no-op.

buf_read_ahead_pages() releases the tablespace reference
on a failed/corrupted page.

btr_ra_latch: A caller-owned buffer of leaf page numbers, which also
records the level-1 page and the child page number of the last node
pointer collected, so read-ahead can be resumed later.

btr_ra_collect(): Scan the node pointers of PAGE_LEVEL=1 page from
the given record in scan order, appending child page numbers

btr_cur_t::search_leaf(), btr_cur_t::open_leaf(): At PAGE_LEVEL=1,
after the descent has located the child to follow, harvest leaf page
numbers starting at that child in the scan direction. These are
exactly the leaves the cursor will visit, so prefetch is precise
regardless of physical page numbers.

btr_ra_resume_rec(): Locate the record from which read-ahead should
resume, by re-finding the last harvested child by value. It walks only
genuine records, so a concurrent page reorganization cannot cause
an invalid read

btr_pcur_move_to_next_page(): Prefetch the sibling after the
one being entered, with buf_read_ahead_one().

btr_pcur_move_backward_from_page(): Add a no-wait fast path that
latches the previous page if it is resident
(validating it against the current page), and prefetch
the one before it.

btr_copy_blob_prefix(): Simplified; no longer relies on
FIL_PAGE_PREV/NEXT, which are not initialized on BLOB pages.

records_in_range() reports the first and last leaf page of a
range, and the optimizer forwards that extent to the engine through
handler::advise_page_range().

multi_range_read_info_const() takes a page_range parameter;
the default MRR implementation aggregates the
per-range extents, and opt_range.cc carries the result through the
chosen QUICK_RANGE_SELECT, whose reset() calls advise_page_range()
before multi_range_read_init(). The extent only sizes and bounds
read-ahead; it never gates the pages the scan actually reads.
The LIMIT is converted in multi_range_read_info_const() to a
leaf count (m_ra_limit_pages).

mrr_readahead_from_scan_range() derives the read-ahead ceiling
from the advised extent, falling back to that LIMIT-based estimate.
The ceiling is capped by init_readahead_window() at 1/256 of
the buffer pool (but at least 4 pages), because every prefetched
page occupies a buffer pool frame as soon as its read is issued.

The window ramps up: a positioning read harvests at most 4 leaves
and resets the window to 4, and readahead_refill() doubles it
toward the ceiling. Single-row probes such as index_first()
for MIN()/MAX(), and every range of a multi-range read,
therefore prefetch only a few leaves while long scans reach
full depth.

search_with_readahead(): Position the cursor while collecting the leaf
pages, then call start_readahead(). It is used by
index_read() and by the first general_fetch() only when
read-ahead is armed, so the other paths carry no read-ahead locals.

start_readahead(): For a just-positioned scan, prefetch the collected
batch and set up the rolling cursor.

readahead_refill(): As the scan advances (general_fetch()),
resume the level-1 harvest under an index S-latch, chain across
level-1 siblings, and prefetch the next batch bounded by the
advised last leaf, or to the end of the index when the extent
is unknown. The reads are issued after the latches are released.

Read-ahead is started from index_read() (range and full index scans),
rnd_init()/general_fetch() (full table scans), and, at one-page depth,
from row_merge_read_clustered_index() (OPTIMIZE/ALTER rebuild).
general_fetch() sets active_handler_stats before issuing
read-ahead so prefetched pages are attributed to the query.

dict_stats_analyze_index_for_n_prefix(): Choose the records to dive
below first, prefetch their child pages in one batch with
buf_read_ahead_pages(), and then dive below the same records.

Undo/system tablespace shrinking holds fil_space_t::latch exclusively
(x_lock_space()), and buf_read_ahead_undo() holds it shared,
via the new fil_space_t::s_lock_try() that never waits,
while it checks the size and issues the reads.
If the latch is not available, the read-ahead is skipped.

trx_undo_get_prev_rec(), trx_undo_get_prev_rec_from_prev_page():
take the trx_undo_t object instead of a long parameter list and
always latch shared.

594957938759...

594957938759dd90cc14973698ce85bd6c5b8a55

Sergei Petrunia

sergey@mariadb.com

No MDEV: include/opt_context_save_in_var.inc can't handle quotes

I_S.OPTIMIZER_CONTEXT has this statement:

set @opt_context='CONTEXT'; -- denote CONTEXT-STMT

And opt_context_save_in_var.inc just took the CONTEXT and put it
in a variable:

SET @opt_context= (select REGEXP_SUBSTR(...) from i_s.optimizer_context);

This ignored the fact that the "CONTEXT" is escaped for the SQL parser.

Fix this by extracting the entire CONTEXT-STMT and running it.

53a392583048...

53a392583048aa29239959ffc9878300a79f352b

Sergei Golubchik

serg@mariadb.org

MDEV-41253 RPM %pre scriptlet unconditionally resets a pre-existing mysql user's home directory to /nonexistent

keep resetting to not writable, but use an existing path

3f4397d380e5...

3f4397d380e5dd5a1b3bd3eb23bd86c523cd9469

Marko Mäkelä

marko.makela@mariadb.com

fixup! e47670210df01f9f7cf91984c79714bbf6fa89b7

38bc5b954b88...

38bc5b954b88bc8004bc1d3a10894250cbcde807

drrtuy

drrtuy@gmail.com

MDEV-40957 replication from InnoDB into DuckDB works using FULL mode only.

36f36cee3eac...

36f36cee3eacbeab95db92f2d4f9643256f639e1

Sergei Golubchik

serg@mariadb.org

workaround for https://bugzilla.redhat.com/show_bug.cgi?id=2390105

34e3dc803852...

34e3dc803852a36d41c471af9048563c73070772

drrtuy

drrtuy@gmail.com

MDEV-40957 DuckDB engine now returns maximum cost for unimplemented index handler operations effectively disabling them.

322658cd4423...

322658cd442333a13b46521d1acca67d1e8366cb

Sergei Golubchik

serg@mariadb.org

fix building of external plugins

ARG_DEPENDS might be empty.

tests should be under <pluginname>/ not under whatever build dir happened
to be named.

2db22df80520...

2db22df80520f0196b0c518e6bb146b07739ff3f

bsrikanth-mariadb

srikanth.bondalapati@mariadb.com

MDEV-41340: Don't push down statements that use a view in FederatedX

A multi-table UPDATE or DELETE referring to a view (merged or
materialized) was pushed down whole to the remote server. The pushed
statement is printed with the view name, which exists only on the local
server, so the remote server failed to find it.

Reject views in get_fed_table_for_pushdown(): a table list entry for
which is_view() is true makes the pushdown decline, and the statement
is executed locally, row by row.

get_fed_table_for_pushdown() is shared by the select, unit, derived and
multi-table UPDATE/DELETE handlers, so SELECT and INSERT ... SELECT
referring to a view are no longer pushed down with the local view name
either.

The view's own body can still be pushed as a derived table (shown as
PUSHED DERIVED in EXPLAIN); only the outer statement is not pushed.

Add tests to federatedx_pushdown_upd_del covering multi-table UPDATE
and DELETE with a materialized (LIMIT) view and with a mergeable view,
a merged view over several tables, a view of a view, a view inside a
subquery, and SELECT and INSERT ... SELECT from views.

250ee9121fc1...

250ee9121fc18863086ac785914f181862acbb87

drrtuy

drrtuy@gmail.com

MDEV-40957 read-free DML on the slave for DuckDB.

2340857fa1e8...

2340857fa1e803202783c33ae379a7484bbf038f

Khaled Riyad

khaled57.dev@gmail.com

MDEV-40377 Change Server source code to point to new docs (11.4 part)

Replace the remaining Knowledge Base links with their MariaDB
Documentation equivalents, including the 838 URLs in the help tables.
Only URLs change in fill_help_tables.sql.

Merging upward: fill_help_tables.sql conflicts at 10.11->11.4 and
11.8->12.3. At those two merges keep the target branch's version,
since 11.4, 11.8 and 12.3 each carry their own URL fix. From 12.3 to
13.1 and 13.1 to main it merges cleanly; take the incoming change.
.github/pull_request_template.md is deleted in 12.3; keep the deletion.

1aca995275e8...

1aca995275e893a857e428c6b480287cfbb93a63

Alessandro Vetere

iminelink@gmail.com

MDEV-39792 InnoDB: ALTER TABLE FORCE triggers assertion "s" in buf_page_get_gen()

When rebuilding a table from ROW_FORMAT=COMPACT or DYNAMIC into
ROW_FORMAT=REDUNDANT, row_merge_buf_add() fetches the full value of an
externally stored (off-page) CHAR column in a multi-byte character set
and pads it to REDUNDANT's fixed local width via
row_merge_buf_redundant_convert(). That helper already dereferences the
BLOB and calls dfield_set_data(), which clears the field's "externally
stored" flag, since the value is now held in full locally.

The "flag externally stored fields" step further down in
row_merge_buf_add() did not know this had happened. It still consulted
the row_ext_t cache built from the original (pre-conversion) record and,
for a column that is not part of the clustered index's unique key,
called dfield_set_ext() again on the very field that had just been
converted, without restoring its data pointer to a valid 20-byte
external reference. row_merge_copy_blobs() would then read the tail of
the padded, space-filled buffer as if it were a BTR_EXTERN_FIELD_REF,
deriving a garbage tablespace id and crashing buf_page_get_gen()'s
fil_space_get() assertion when the alter tried to build the new
clustered index.

Skip the re-flagging step for a field whose "externally stored" flag is
no longer set. row_build() flags every off-page column, and the
row_ext_t cache only holds a subset of those columns, so a field that
is not flagged is either a converted one (already fully local) or one
that the cache does not hold.

With the field no longer re-flagged, the rebuild completes, and the
rebuilt table passes CHECK TABLE with the full column value.

The MDEV-31025 case in innodb.default_row_format_alter failed on
innodb_page_size=4k and 8k: its ROW_FORMAT=REDUNDANT table has eight
utf32 CHAR(255) columns, which CREATE TABLE rejects with
ER_TOO_BIG_ROWSIZE on those page sizes. Derive the number of columns
from the page size, so that the record still exceeds the maximum local
record size and the fixed-length column c is stored externally. The
whole test now passes on every page size.

1a468b2833a5...

1a468b2833a557dbf2d0c038578b9f253c167787

Sutou Kouhei

kou@clear-code.com

Fix auto directory creation for absolute mroonga_database_path_prefix (#1166)

mkdir_p() tried stat("") and mkdir("") for the leading directory
separator of an absolute path and gave up. So we couldn't create
database directory automatically for absolute
mroonga_database_path_prefix such as "/var/lib/mroonga/".

This also treats EEXIST from mkdir() as success because another process
may create the directory after our stat().

Assisted-by: Claude:claude-5.5-opus

19719d64f025...

19719d64f0252bd2e0950457c46fdea90b1cfcbc

ParadoxV5

paradox.ver5@gmail.com

MDEV-38849 slave_connections_needed_for_purge prevents independent machine from purging binary logs

`@@slave_connections_needed_for_purge`’s default of `1` ensures binary
log availability on replication masters, but is not a sensible default
suitable for all scenarios, especially for long-term slave servers and
standalone (not in a replication setup) servers.
The outcome was that standalone server users were confused why automatic
binlog purging does not work.

This commit changes this default to `0`, which is suitable for both
standalone and (when backed by prompt failure recovery)
replication setups.
`0` also more closely matches the behaviour before MDEV-31404,
which added this variable, out of the box.

This commit also adds a one-time replication warning when registering a
slave, but `@@slave_connections_needed_for_purge` is left unchanged.
Rather than enforcing a defence with an unsensible default, this
reminder will bring awareness of the risk of automatic binlog purging.

This commit also cleans up Galera and MTR workarounds to the
introduction of the `@@slave_connections_needed_for_purge=1` default.

189298bd2a36...

189298bd2a36d1e14c076339404563ec04bd315c

drrtuy

drrtuy@gmail.com