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
fffe55f39cef...
fffe55f39cef9e077112f5e9abde3d8dd11ba492
Khaled Riyad
MDEV-40377 Change Server source code to point to new docs (12.3 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.
f49e838d367f...
f49e838d367f2154b3edb43effa99ff9eb0d8602
DerZc
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
Merge branch '11.4' into 11.8
ef9134ac4933...
ef9134ac4933c30a3af9851050a0c5df5487c308
Dave Gosselin
CSV:  Keep the data file length when a lock wait fails

Keep the data file length in the share of a CSV table when a statement
fails to get its table lock.

After FLUSH TABLES t1, while another connection holds LOCK TABLES t1
READ LOCAL, UPDATE t1 SET v=v+10 fails with a lock wait timeout, and
the next SELECT * FROM t1 returns no rows.  The UPDATE opens a new
handler, whose own length is 0 until thr_lock grants the lock.  The
unlock after the failed wait stores that length in the share.

A handler now uses the length in the share from external_lock() until
thr_lock grants the lock, and an unlock without that grant leaves the
length in the share as it was.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
ecda07c65644...
ecda07c6564488ba0c807dcbdcfa3bea4b486ed9
Dave Gosselin
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]>
e457d7f51f77...
e457d7f51f773351abbe48f8c22687c5ac7c7817
Dave Gosselin
MDEV-41216:  ha_tina (CSV) deletes wrong records

Refuse a DELETE or UPDATE that changes rows of a CSV table through two
aliases.

In DELETE a1, a3 FROM t1 AS a1 JOIN t1 AS a3 WHERE a1.v=2 AND a3.v=1,
each alias saves the file offsets of its rows during the join and
deletes them in a later pass.  The end of the first pass rewrites the
data file without its deleted rows, so the offsets saved by the second
alias point at other rows.  The statement deletes the wrong rows or
marks the table as crashed, and an UPDATE through two aliases fails the
same way.

When two targets of a DELETE or UPDATE are the same CSV table,
including through a view, the statement fails with ER_NOT_SUPPORTED_YET
when it is prepared, and the message names both aliases.  For UPDATE
the check sits next to the existing one for a clustered primary key or
partition key updated through two aliases.

A multi-table UPDATE also fails with ER_NOT_SUPPORTED_YET when the
CHECK OPTION of an updated view reads an alias of a CSV table that the
statement changes through another alias.  The CHECK OPTION reads the
rows of that alias again by the positions saved during the join.  Any
other statement where one alias changes rows and the other only reads
them runs as before.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
dddbd5ff4278...
dddbd5ff427894941fee3d7528ca2058e026b82e
Aleksey Midenkov
MDEV-41344 Timestamp conversion does not work for TRADITIONAL mode

Field_temporal::get_copy_func() returns do_field_datetime whenever the
session's sql_mode has NO_ZERO_DATE or NO_ZERO_IN_DATE (e.g. under
sql_mode=TRADITIONAL), or when the two fields are not eq_def(),
regardless of whether the field is a system-versioned
row_end.

get_copy_func() checked for that value and returned early, before ever
reaching the VERS_ROW_END check that installs
do_field_versioned_timestamp. So an ALTER TABLE .. FORCE meant to
convert an old-format row_end silently copied the value unchanged
instead: the conversion check correctly demanded a copy, but the copy
step never applied it, with no error or warning.

The fix checks the row_end conversion need first, independently of
what Field_temporal::get_copy_func() picked. row_end is
server-maintained and never zero, so NO_ZERO_DATE does not apply to
it.

Tested by "traditional" combination in old_timestamp.test, the test
restores real pre-11.5 row_end fixtures and runs mariadb-upgrade
--force.
d22d9e74773c...
d22d9e74773c6c6e797884df2fafb5c08e1be421
Brad Smith
MDEV-41221: memcpy() source and target overlap in dict_table_rename_in_cache()

In dict_table_rename_in_cache(), sql_id = foreign->sql_id() points into
the existing foreign->id string. When the new id is not longer than the old
one (always the case when renaming from "#sql-alter-..." back to the real
table name), the buffer is reused in place, so the final
snprintf(id, fklen, "%s\377%s", table->name.m_name, sql_id)
reads sql_id from the buffer it is writing to (sql_id == id + 50 in gdb).
That is undefined behavior. Most libcs happen to copy forward and get away
with it, but OpenBSD's memcpy detects the overlap and calls abort().

The fix computes the lengths explicitly, memmove()s the sql_id tail to its
final position first, then memcpy()s the table name prefix and writes the
\377 separator. The decision to reuse the old buffer or allocate a new one
is unchanged.

Co-authored-by: Claude Opus 5.5 <[email protected]>
ce029f6148fc...
ce029f6148fc05c477741aa4585edc8432feafc9
Dave Gosselin
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]>
cd2b2ef88117...
cd2b2ef88117b3bc5c2133c1d4e780a1a9a9e97b
Dave Gosselin
CSV:  Share the data file length among handlers of one lock

Under LOCK TABLES t1 WRITE, t1 AS a1 WRITE, rows added or changed
through t1 were missing when read through a1, and after UNLOCK TABLES
a row could stay hidden from every later query.  Each handler kept its
own copy of the data file length, taken when the table was locked, and
the last handler to unlock wrote its copy back to the share.

The CSV engine now registers a copy_status callback, as MyISAM does.
When one lock call holds a table more than once, all handlers of that
table use the length of the first handler, so a write through any of
them is seen by the others.  Only the first handler stores that length
in the share, because the others can unlock after it is closed.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
b6398296aeee...
b6398296aeeeb253bdb3d1dd1620d2bb03836bf7
Khaled Riyad
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
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]>
b03be66c0d07...
b03be66c0d0799379a087e33677ec0c562ab4ec0
Dave Gosselin
CSV:  Read rows written under LOCK TABLES in CHECK and REPAIR

Make CHECK TABLE and REPAIR TABLE on a CSV table read the rows written
while the table is locked.

Under LOCK TABLES t1 WRITE, INSERT INTO t1 VALUES (4) followed by
CHECK TABLE t1 reports the table as corrupt, and the next statement
fails because the table is marked as crashed.  check() and repair() set
the data file length from the share, which keeps the length from the
time of the lock until UNLOCK TABLES stores the new one.  The scan stops
before the inserted row, and the row count does not match.

CHECK now scans to the end of the data file, because the row count
includes every row written so far.  Under LOCK TABLES t1 READ LOCAL,
the count also includes the rows that another connection inserted after
the lock, which the length of the locked handler misses.  The handler
keeps its own length for the statements that follow under the same
lock.  REPAIR scans to the end of the data file too, so that it removes
the bad rows that CHECK reports, such as a row that another program
appended to the file under LOCK TABLES t1 WRITE.

An INSERT now writes and counts its row under share->mutex, and CHECK
reads the row count and the file length under the same mutex, so that
the two agree when another connection inserts a row during CHECK
TABLE.  The constructor sets curr_lock_type to F_UNLCK, so that it has
a value before the first call to external_lock().

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
adc979f54ddb...
adc979f54ddbaf6a2a51a536aefc5e9cbefb328f
Sergei Golubchik
Merge branch '11.8' into 12.3
94a62664bd71...
94a62664bd7136987aefe3c80a020c0f9cd30eb2
Rucha Deodhar
MDEV-41181: ASAN heap-buffer-overflow after SELECT JSON_SCHEMA_VALID
91b30e2cc15a...
91b30e2cc15a0ae3f3a2ad3276885cf645bdf617
Alexander Barkov
MDEV-41265 SELECT/ UPDATE RETURNING INTO a single row-field fails with ER_WRONG_NUMBER_OF_COLUMNS_IN_SELECT, even though the column count matches

my_var_sp_row_field::check_assignability() and
my_var_sp_row_field_by_name::check_assignability() had an inverted
condition. They returned true (error) when the select list had exactly
one element, and false (OK) otherwise.

A field of a ROW variable (r0.a) is a scalar target, so it accepts
exactly one column. The check must fail when the number of select list
elements is not 1:

  SELECT a INTO r0.a FROM t1;    # was wrongly rejected, now works
  SELECT a,b INTO r0.a FROM t1;  # was wrongly accepted, now fails with
                                  # ER_WRONG_NUMBER_OF_COLUMNS_IN_SELECT

Fix: change 'select_list.elements == 1' to 'select_list.elements != 1'
in both classes.

Tests added to select_into_row.test for fields of:
- an explicit ROW variable
- a ROW TYPE OF table variable
- a ROW TYPE OF cursor variable
Each covers the one-column (OK) and two-column (error) cases.

The bug was introduced in two steps:
- a91b78049a8 MDEV-36705 added my_var_sp_row_field with the inverted
  condition.
- add63991988 MDEV-40790 copied it into the new class
  my_var_sp_row_field_by_name.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
8f3cadfb8e39...
8f3cadfb8e39f303c9401f6cfbf2573acca55b7a
Georg Richter
MDEV-40146 vio_gencert function doesn't set serial number

this apparently breaks RFC 5280, and makes python cryptography module
unhappy.
8dddd70215a6...
8dddd70215a68e26117178f730751a2e141ab9f8
drrtuy
MDEV-40957 MTR  tests to cover DML statements in a replicated setup.
7a18746354a8...
7a18746354a847d8cff7487fcbfda4965358fe06
Sergei Golubchik
Merge remote-tracking branch 'github/12.3' into bb-12.3-serg
78fe5219d370...
78fe5219d3705eedd87de85c6a15afd06cbaacd9
Sergei Golubchik
Merge branch '11.8' into 12.3
6f8a8ed49ad3...
6f8a8ed49ad3ae5a375943ca29bc9b166a3bf8fa
Dave Gosselin
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
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.
69d1ca979535...
69d1ca979535ba612b47b68998a0fb1dd45a9ea7
Dave Gosselin
CSV:  Keep the row when an UPDATE fails to write its new version

When an UPDATE on a CSV table failed to write the new version of a row
to the temporary file, the old version had already been marked for
removal.  The end of the scan still rewrote the data file, so the row
was lost and CHECK TABLE reported the table as corrupt.  A write that
failed partway also left part of the row in the temporary file, which
then joined the next row written after it.

Undo the removal mark when the write fails, so the old row stays in the
table.  Move the write position of the temporary file back to its last
good length, where the next write replaces the part of the failed row.
The end of the scan cuts the temporary file to the length of the rows
written, which removes any part that no later write replaced.  If the
write position cannot be moved back, the end of the scan leaves the
data file unchanged, and the rows updated before the failed one keep
their old values.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
64929e06781b...
64929e06781b69f79e243a57a0cee7b291f0753f
Brad Smith
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.
4bf178391e9f...
4bf178391e9f1aac333eb6f97fa3ab2a63288fa0
Aleksey Midenkov
MDEV-41050 versioned DELETE via row_end index leaves a row undeleted

1. Aria/MyISAM engines

A system-versioned DELETE on a MyISAM or Aria table indexed by row_end
could leave the last current row undeleted. The delete scans the current
rows via an equality search on row_end = MAX, which is driven by
mi_rnext_same/maria_rnext_same. That function keeps the search's
reference key in lastkey2 and uses the HA_STATE_RNEXT_SAME flag to
remember it has already stored it. This reference-key mechanism is
exactly what lets the scan modify rows it is walking without skipping
them.

Deleting a versioned row is an in-place update of row_end, and the update
reuses lastkey2 as scratch space for the changed key, so it clears
HA_STATE_RNEXT_SAME to request that rnext_same re-store its reference on
the next call. However, TABLE::delete_row wraps the update in
HA_EXTRA_REMEMBER_POS/HA_EXTRA_RESTORE_POS, and RESTORE_POS restored the
whole saved info->update word, resurrecting the HA_STATE_RNEXT_SAME bit
that the update had just cleared.

As a result rnext_same skipped rebuilding its reference key and compared
subsequent keys against the now-overwritten lastkey2, hitting a spurious
end-of-file and terminating the scan one row early, defeating the engine's
own protection against a Halloween-style skip.

Fixed by preserving the current HA_STATE_RNEXT_SAME bit across
RESTORE_POS instead of restoring the stale saved value. See also the HEAP
fix below: same root cause, different per-engine mechanism.

2. HEAP engine

The row loss also reproduces on the MEMORY (HEAP) engine. A system-
versioned DELETE scans the current rows on the row_end index and turns
each delete into an in-place update of row_end, so it modifies the very
index it is walking.

When the changed key is the scanned one (info->lastinx), hp_delete_key()
repositions the cursor but heap_update() leaves info->update untouched, so
HA_STATE_NEXT_FOUND from the preceding heap_rnext() stays set. The next
heap_rnext() then sees current_ptr == 0 with that bit and takes the
"!current_ptr && HA_STATE_NEXT_FOUND" guard as a false end-of-file,
stopping one row early.

Fixed by clearing HA_STATE_NEXT_FOUND when the scanned index key changed.
HA_STATE_AKTIV is kept (unlike heap_delete): the row is updated, not
removed, so a following op must not fail test_active(). The bit is only
set after a heap_rnext(), so a plain single-row UPDATE never reaches this.
See also the Aria/MyISAM fix above: same root cause, different per-engine
mechanism.

3. Why the fix differs per engine, and InnoDB

Aria and HEAP both trace their handler design back to MyISAM, hence the
same root cause (stale scan bookkeeping after an in-place key change) in
all three, fixed at each engine's own bookkeeping spot. InnoDB needs no
fix: its persistent cursor survives concurrent index modification by
design, already covered by this same test under the timestamp
combination (default-storage-engine=innodb), which passes unmodified.
3f0b82d2ba43...
3f0b82d2ba43d4c063f55a44248e75e44b8d6dca
Jan Lindström
MDEV-40038 tp_foreach() crashes on a dying transaction participant

Bug: tp_foreach() found an engine in hton2plugin[] and passed the
result of plugin_lock() to plugin_hton() without a check. While
reap_plugins() deinitializes an uninstalled engine (PLUGIN_IS_DYING),
the slot stays set until the end of ha_finalize_handlerton(), and
plugin_lock() returns NULL. The server crashed in plugin_hton(), for
example in RESET MASTER through ha_commit_checkpoint_request().

This is a regression from aed5928207a, which changed plugin_foreach()
to tp_foreach() and lost the PLUGIN_IS_READY state mask.

Fix: add plugin_lock_ready(), which locks only a PLUGIN_IS_READY plugin
and reports under LOCK_plugin whether a failed lock was for a READY
plugin (out of memory in debug builds). tp_foreach() skips a plugin that
is not READY and returns an error for a READY plugin that cannot be
locked. An uninstalled but busy engine (PLUGIN_IS_DELETED) is not
visited, as with plugin_foreach() before.

The test uses a DEBUG_SYNC point in ha_finalize_handlerton() to run
RESET MASTER while an engine is deinitialized.

Assisted-by: https://mariadb.org/governance/governance-ai-policy/
3ee413a5374b...
3ee413a5374bf8339e5f124f0ada55b1935fc5af
Dave Gosselin
MDEV-41216:  Tests for CSV DELETE and UPDATE through two aliases

Add tests where two aliases of the same CSV table change rows in one
DELETE or UPDATE, in a plain statement, under LOCK TABLES and in a
stored function.  These statements must fail with ER_NOT_SUPPORTED_YET
and leave the table unchanged, so the tests fail until the server
refuses them.  Statements where one alias changes rows while the other
only reads them still succeed.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
38bc5b954b88...
38bc5b954b88bc8004bc1d3a10894250cbcde807
drrtuy
MDEV-40957 replication from InnoDB into DuckDB works using FULL mode only.
365d2d1f3e61...
365d2d1f3e616c0c89c14bd9a4a420834ae35c28
chiri
crc32c_x86: drop the AVX512DQ requirement
34e3dc803852...
34e3dc803852a36d41c471af9048563c73070772
drrtuy
MDEV-40957 DuckDB engine now returns maximum cost for unimplemented index handler operations effectively disabling them.
335eca6b25e6...
335eca6b25e6db3a12ae6bd6913414866c7e35b4
Dave Gosselin
CSV:  Remove the partial row that a failed INSERT leaves

Cut the data file of a CSV table back to its length before the write
when an INSERT fails to write its row.

When the write of row 2 stops after its first byte, INSERT INTO t1
VALUES (2) fails, but that byte stays at the end of the data file.  The
next INSERT INTO t1 VALUES (3) appends its row after it.  Once the
table is opened again, SELECT * FROM t1 returns the rows 1 and 23, and
CHECK TABLE reports the table as OK.

If the cut fails too, the table is marked as crashed.  A new debug
injection point writes the first byte of a row and then fails as if
the disk were full, and the new test uses it.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
322658cd4423...
322658cd442333a13b46521d1acca67d1e8366cb
Sergei Golubchik
fix building of external plugins

ARG_DEPENDS might be empty.

tests should be under <pluginname>/ not under whatever build dir happened
to be named.
250ee9121fc1...
250ee9121fc18863086ac785914f181862acbb87
drrtuy
MDEV-40957 read-free DML on the slave for DuckDB.
2340857fa1e8...
2340857fa1e803202783c33ae379a7484bbf038f
Khaled Riyad
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.
1ca6a438535f...
1ca6a438535fef8a643c414e2782b3987e0fc78e
Dave Gosselin
CSV:  Test a failed write during UPDATE

Add two debug injection points to the CSV engine.  One writes the first
byte of the new version of a row and the other writes all of it, and
both then fail as if the disk were full.  The new test uses the first
to check that UPDATE keeps the old rows and that the table is not
marked as corrupt afterwards.  A second case fails on the second row
and checks that the first row keeps its new version, which covers
moving the write position of the temporary file back.  A third case
fails on a new version that is longer than the rest of the table, and
checks that no part of it reaches the data file, which covers the cut
of the temporary file at the end of the scan.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
1aca995275e8...
1aca995275e893a857e428c6b480287cfbb93a63
Alessandro Vetere
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.
19719d64f025...
19719d64f0252bd2e0950457c46fdea90b1cfcbc
ParadoxV5
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
MDEV-40957 mixed-mode replication UPDATE/DELETE for DuckDB.
17cc6b376784...
17cc6b376784df4fdbab2514a29311bf4367e81c
Khaled Riyad
MDEV-40377 Change Server source code to point to new docs (11.8 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.
15174ecd8efe...
15174ecd8efe4a2cc95cb00c8fc6b01e8a54b484
drrtuy
MDEV-40957 various fixes for mixed DML path that suffered from uninit bitmaps and wrong SQL statements that failed in DuckDB.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Wed 07 Oct 2026 20:01:10 (UTC)