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
f81cc78cfcbe...
f81cc78cfcbe3a722901578154f7753fec4ea8ba
Rex Johnston
MDEV-35673 stable outer-reference resolution across executions (2/3)

Split from MDEV-32294, discovered while inspecting how
Item_subselect::used_tables_cache is recalculated across the 1st and 2nd
executions of a prepared statement.

Name-resolution permanence:
- Preserve Item_field::depended_from across executions and use it in
  fix_fields/fix_outer_field instead of re-running the outward search,
  so 2nd-execution resolution is stable.
- find_field_in_tables: wrap a HAVING outer reference in an Item_ref
  during name resolution (previously done only in
  Item_field::fix_outer_field, now shared via
  fix_field_reference_to_having()), fixing a marked_for_read()
  assertion on queries such as
    SELECT 1 FROM (SELECT a FROM t1) b HAVING (SELECT b.a)=1
- create_view_field: resolve view-field substitutions against
  current_select and allocate them on statement memory.

Bookkeeping consumed by the next commit:
- Maintain SELECT_LEX::outer_references_resolved_here, a
  statement-memory list of the outer references resolved in each
  select_lex (relies on MDEV-30073 so these are not freed at end of PS
  execution), populated in st_select_lex::mark_as_dependent and kept
  correct across derived/semi-join merges (merged_into, nest_level /
  nest_level_base maintenance, select_update_base_processor).
  Item_subselect::recalc_used_tables() itself is rewritten in the next
  commit; until then the 2nd-execution guard from MDEV-30073 remains in
  Item_subselect::update_used_tables(), so re-executions run on the
  used_tables_cache computed by the first execution.

Ban EXPLAIN EXTENDED under the mtr --ps-protocol (warning output differs
because some select_transformers no longer run during PREPARE).

Remove select,ps.rdiff / select_jcl6,ps.rdiff / select_pkeycache,ps.rdiff:
the doubled "resolved in SELECT #1" notes they recorded no longer appear
under --ps-protocol.

main.union: the MDEV-29022 queries (UNION ordered by scalar subqueries
referencing the union columns by alias) are temporarily disabled: with
the interim used_tables handling they return misordered rows on the 2nd
execution under --ps-protocol.  Re-enabled by the next commit, which
fixes them.

main.subselect_mat_cost_bugs: the derived-table query whose correlated
WHERE subquery produces two 'Truncated incorrect DECIMAL value'
warnings loses those warnings on the 2nd execution under --ps-protocol
at this commit; its warnings are disabled here and re-enabled by the
next commit, which fixes the discrepancy.

Tests: extend main.outer_reference with the cases fixed by this commit
(view/derived/CTE-merged outer references, GROUP BY/ORDER BY subqueries,
MDEV-32297, MDEV-6054).

This commit was prepared with Claude Code: it partitioned the original
MDEV-35673 commit empirically (building and running the full SQL-layer
suites, both protocols, at each candidate boundary), verified that this
intermediate state is green apart from the two documented cases above,
moved the rdiff removals here from MDEV-40465 where they had gone stale,
and drafted this commit message.
ed90fadb18e1...
ed90fadb18e16eb9812d0d9b39f70128e1fb97db
Rex
MDEV-40465 table map consulted during setup fields on unfixed items

In setup_fields() we call item->update_used_tables() before split_sum_func
so that used_tables() is not consulted before the caches are set up on the
2nd execution of a prepared statement.  This fixes a 1st/2nd execution
main.win --ps-protocol failure noted in the previous commit (the window
function's correlated argument looked constant to split_sum_func2, so no
Item_ref into the window temp table was created on re-execution).

That recalculation exposes items whose caches are read while still being
(re)built, so add the guards it now depends on:
- Item_field::used_tables(): return 0 when field / field->table is not
  yet set, instead of dereferencing a null pointer.
- Item_func::fix_fields(): reset used_tables_cache/const_item_cache at
  entry (assignment) instead of asserting they are already clear, so a
  re-fix is idempotent.

The --disable_ps_protocol wrapper placed around the main.win
MDEV-18431 query by the previous commit is removed: that query now
returns identical results on the 1st and 2nd execution.

Claude Code relocated this commit's rdiff removals to an earlier commit
of the series (where the recorded differences actually disappear) and
updated this message accordingly.
e3e8bb053f40...
e3e8bb053f40460622691d1ba8d6cbf67d8b7e14
ParadoxV5
MDEV-39880 Reïmplement MDEV-37146 to include MDEV-39519

MDEV-39519 added MySQL 8 compatibility to `mariadb-dump --dump-slave`
by attempting `SHOW REPLICA STATUS` first and then `SHOW SLAVE STATUS`.
This conflicted with MDEV-37146, where `mariadb-dump --dump-slave`
queries either `SELECT … FROM information_schema.SLAVE_STATUS`
or `SHOW ALL SLAVES STATUS` depending on the server version.

This commit merges MDEV-37146 and MDEV-39519:
* Use MDEV-39519’s strategy based on syntax error handling.
* Use MDEV-37146’s preference order:
  1. `SELECT … FROM information_schema.SLAVE_STATUS`
  2. `SHOW ALL SLAVES STATUS`
  3. `SHOW REPLICA STATUS` (for MySQL compatibility _only_)
* Send `STOP`/`START REPLICA SQL_THREAD FOR CHANNEL '…'`
  commands for both MariaDB (est. 10.7) and MySQL.
* Refactor column indices to variables set when a query succeeds.
* Partially revert MDEV-37146’s removal of `--dump-slave`’s support for
  pre-GTID & pre-multi-source, but tailored for MySQL compatibility;
  coverage for MariaDB pre-10.0 is not fully restored.
dc2ebbe6f978...
dc2ebbe6f9781bce88fe990ccc9e4ec4d23290fb
Rex Johnston
MDEV-35673 rewrite Item_subselect::recalc_used_tables() (3/3)

Item_subselect::used_tables_cache was computed from upper_refs, a list
of Ref_to_outside snapshots taken at the first fix_fields().  Those
snapshots record the select the reference resolved in at that moment;
view merges, derived-table merges and semi-join conversions performed
later leave them pointing into merged-away selects, and they cannot be
rebuilt on re-execution.  The stale walk mis-classifies references, so
a correlated subquery can be treated as constant/uncorrelated.

Visible effects fixed here:
- server crash (SIGSEGV in sub_select) on plain execution of
    ( SELECT a c28 FROM t0 LIMIT 5 )
      ORDER BY ( SELECT c28 FROM t0 LIMIT 1 );    (MDEV-32766)
- UNION ... ORDER BY (scalar subquery referencing a union column by
  alias) returning misordered rows on the 2nd execution of a prepared
  statement (main.union, MDEV-29022 queries re-enabled here).

recalc_used_tables() now computes the map from
SELECT_LEX::outer_references_resolved_here (populated by the previous
commit and kept correct across merges), classifying each reference with
item_belongs_to()/Field_fixer against the merged_into chain.

With recalculation now valid on every execution:
- Item_subselect::cleanup() clears used_tables_cache and the FIXED
  flag, so each execution recomputes rather than reusing the previous
  execution's map;
- the temporary 2nd-execution guard in
  Item_subselect::update_used_tables() (from MDEV-30073) is removed;
- Item_subselect::mark_as_dependent() no longer builds Ref_to_outside
  entries during PS context analysis (upper_refs is no longer the
  source of used_tables_cache);
- Item_direct_view_ref::used_tables() returns 0 for a not-yet-fixed
  item instead of asserting, as recalculation can now run while items
  are being re-fixed.

main.win: the MDEV-18431 query (window function + correlated subquery
in one select-list expression) reads a stale used_tables_cache in
split_sum_func at re-execution and returns wrong results on the 2nd
execution under --ps-protocol; it is run with --disable_ps_protocol at
this commit.  The next commit (MDEV-40465) recomputes used_tables in
setup_fields before split_sum_func, fixes this, and removes the
wrapper to demonstrate it.

main.subselect_mat_cost_bugs: the warnings disabled by the previous
commit are re-enabled; the 2nd execution produces them again.

Tests: the remaining main.outer_reference case (MDEV-32766) is added.

This commit was prepared with Claude Code: it isolated the rewrite plus
its activation as the minimal unit that cannot be split further (any
intermediate state returns wrong results on re-execution), confirmed the
MDEV-32766 crash pre-exists on an unpatched 10.11 build, and drafted this
commit message.
db0d0d4e46e3...
db0d0d4e46e390bfe74e6ef4ea95fdf651e4d01d
Dave Gosselin
MDEV-35747:  Wrong result from prepared TVC with parameter markers

The setup of column type information in table_value_constr::prepare()
was wrapped in an "if (!holders)" guard so that it runs only once per
statement.  However, the guard was too wide because it bound the
allocation of item holders (which should happen only once) to the
collection of type information (which should happen on each execution).

This leaves the TVC stuck with whatever placeholder type the parameter
had when the holders were first built, which may not match the type of
the next substitution.  A parameter marker has no type of its own until
a value is bound at EXECUTE time.  So both the TVC types and the
corresponding Item_type_holder instance in the SELECT item list must be
computed again on every EXECUTE.

Type holder allocation happens on the first call to the prepare()
function but that doesn't always coincide with a PREPARE.  It does for a
prepared statement whose table value constructor comes from the parser.
For a statement of a stored procedure, and for a table value constructor
that the conversion of an IN predicate into an IN subquery creates,
allocation happens instead on the first execution.  The corresponding
assertion allows the first execution and conventional execution as well
as PREPARE.

This patch separates the work done once per statement from the work done
on every execution as described above.
cded2b25e658...
cded2b25e65853a75c2213cfe0832819832708bd
Daniel Black
MDEV-40512: wsrep fails to compile due to missing filesystem.h

On SLES-1507.

Filesystem was still experimental in gcc 7 so scope accordingly.
c8d42af13b71...
c8d42af13b71815a3bb2a0d816504fd64b1a3323
ParadoxV5
Cherry-pick MDEV-39485

Merge conflict resolution with MDEV-30128
c81bd168e56f...
c81bd168e56fa364cbde1ea72903d5d1ac9a2959
Rex Johnston
MDEV-30073 Wrong result on 2nd execution of PS for query with NOT EXISTS

Summary: Items of type Item_direct_view_ref which are reverted with the
change_item_tree mechanism are involved in permanent optimizer
transformations.  This commit ensures that items involved in these
permanent transformations are created during the first execution
and re-used for subsequent executions.

Queries affected by this bug are numerous, but will always involve
1) 2nd execution of a prepared statement or procedure
2) a permanent transformation, such as a semi-join optimization

Detail:

Consider this run as a prepared statement
SELECT * FROM t1
  WHERE EXISTS
  (
    SELECT dt.a FROM
      (
        SELECT t2a as a, t2b as b FROM t2
      ) dt
      WHERE dt.b = t1a
  )

During name resolution of field dt.b (in the where clause) we end
up calling find_field_in_view()/.../create_view_field().
This is responsible for creating a wrapper around the found Item
(Item_field*)`test`.`t2`.`t2b`
While this Item_direct_view_ref representing 'dt.b' is allocated on
Statement (permanent) memory the change is registered to be reversed
at the end of statement execution.  This is odd and contrary to the
permanent nature of this transformation.

Item::exists2in_processor() is called during the preparation in the
first execution.
We transform the query from
select * from t1 where
exists
(
  select `test`.`t2`.`t2b` from
    (
      select `test`.`t2`.`t2a` AS `a`,`test`.`t2`.`t2b` AS `b` from `test`.`t2`
    ) `dt`
    where `test`.`t2`.`t2b` = `test`.`t1`.`t1a`
    limit 1
)

select * from t1 where
`test`.`t1`.`t1a` in
(
  select `test`.`t2`.`t2b` from
    (
      select `test`.`t2`.`t2a` AS `a`,`test`.`t2`.`t2b` AS `b` from `test`.`t2`
    ) `dt`
    where 1
)

later, the optimizer merges the derived table dt into it's parent

select * from t1 where
`test`.`t1`.`t1a` in
(
  select `test`.`t2`.`t2b` from t2 where 1
)

then this is transformed into a semi-join

select t1.* from t1 semi join t2 on t1a = t2b

At the end of the first execution, the item t2b above is reverted to
dt.b.  During the subsequent name resolution of dt.b, it is resolved
t2a, and the semi-join executed corresponds to

select t1.* from t1 semi join t2 on t1a = t2a

causing a different result set.

Initial Author: Igor Babaev
Reformatted and refactored by: Rex Johnston ([email protected])

Add assert to ensure Item_direct_view_refs are not allocated on
the 2nd execution.

Notes:
Item_exists_subselect implicit LIMIT 1 no longer present during prepare
phase

The find_order_in_list save/reuse is safe: every ORDER reaching it comes
from add_to_list (initialized, sql/sql_parse.cc) or copy-constructed
from those (group_concat, window copies). add_proc_to_list ORDERs are
uninitialized but only reach setup_new_fields, which uses find_item_in_list
directly (~sql/sql_select.cc:27694). Saved select_item points into
select_lex->item_list nodes in statement memory so stable across executions.
c4ad54a1b205...
c4ad54a1b2056d1594afd856fd8c4561630d7760
Rex Johnston
MDEV-35673 stable outer-reference resolution across executions (2/3)

Split from MDEV-32294, discovered while inspecting how
Item_subselect::used_tables_cache is recalculated across the 1st and 2nd
executions of a prepared statement.

Name-resolution permanence:
- Preserve Item_field::depended_from across executions and use it in
  fix_fields/fix_outer_field instead of re-running the outward search,
  so 2nd-execution resolution is stable.
- find_field_in_tables: wrap a HAVING outer reference in an Item_ref
  during name resolution (previously done only in
  Item_field::fix_outer_field, now shared via
  fix_field_reference_to_having()), fixing a marked_for_read()
  assertion on queries such as
    SELECT 1 FROM (SELECT a FROM t1) b HAVING (SELECT b.a)=1
- create_view_field: resolve view-field substitutions against
  current_select and allocate them on statement memory.

Bookkeeping consumed by the next commit:
- Maintain SELECT_LEX::outer_references_resolved_here, a
  statement-memory list of the outer references resolved in each
  select_lex (relies on MDEV-30073 so these are not freed at end of PS
  execution), populated in st_select_lex::mark_as_dependent and kept
  correct across derived/semi-join merges (merged_into, nest_level /
  nest_level_base maintenance, select_update_base_processor).
  Item_subselect::recalc_used_tables() itself is rewritten in the next
  commit; until then the 2nd-execution guard from MDEV-30073 remains in
  Item_subselect::update_used_tables(), so re-executions run on the
  used_tables_cache computed by the first execution.

Ban EXPLAIN EXTENDED under the mtr --ps-protocol (warning output differs
because some select_transformers no longer run during PREPARE).

Remove select,ps.rdiff / select_jcl6,ps.rdiff / select_pkeycache,ps.rdiff:
the doubled "resolved in SELECT #1" notes they recorded no longer appear
under --ps-protocol.

main.union: the MDEV-29022 queries (UNION ordered by scalar subqueries
referencing the union columns by alias) are temporarily disabled: with
the interim used_tables handling they return misordered rows on the 2nd
execution under --ps-protocol.  Re-enabled by the next commit, which
fixes them.

main.subselect_mat_cost_bugs: the derived-table query whose correlated
WHERE subquery produces two 'Truncated incorrect DECIMAL value'
warnings loses those warnings on the 2nd execution under --ps-protocol
at this commit; its warnings are disabled here and re-enabled by the
next commit, which fixes the discrepancy.

Tests: extend main.outer_reference with the cases fixed by this commit
(view/derived/CTE-merged outer references, GROUP BY/ORDER BY subqueries,
MDEV-32297, MDEV-6054).

This commit was prepared with Claude Code: it partitioned the original
MDEV-35673 commit empirically (building and running the full SQL-layer
suites, both protocols, at each candidate boundary), verified that this
intermediate state is green apart from the two documented cases above,
moved the rdiff removals here from MDEV-40465 where they had gone stale,
and drafted this commit message.
c2cafce4cbad...
c2cafce4cbad15a8093d5dd338d59e0973bb9d27
Aleksey Midenkov
MDEV-39063 Server crashes at Item_func_lastval and Item_func_setval with CTE alias

Pure aliases are not handled properly by Item_func_lastval::val_int()
and Item_func_setval::val_int().

This is followup fix for MDEV-33985 where it missed similar cases for
LASTVAL() and SETVAL().

add_table_to_list() does not create MDL request for pure aliases,
i.e. when there is no table_list->db set or TL_OPTION_ALIAS was
set. When the expression is not inside CTE the case with empty db is
handled by:

  else if (!lex->with_cte_resolution && lex->copy_db_to(&db))
    DBUG_RETURN(0);

So, table_list gets current database name and the query is failed with
ER_NO_SUCH_TABLE error.

The fix adds the case of is_pure_alias() check for val_int() methods
and fails it with ER_NOT_SEQUENCE2 error.

Note: semantics for TL_OPTION_ALIAS cannot be based on empty db, only
parser can set TL_OPTION_ALIAS as resolve_references_to_cte() relies
on TL_OPTION_ALIAS after copy_db_to().
bf11805e54cf...
bf11805e54cf1e21319efd121767902850a0a54e
ParadoxV5
MDEV-39788 found that the recent refactor on the `main` (now 12.3)
branch missed the (inconsistent) detail that, unlike `relay-log.info`,
`master.info`’s line count _includes_ the line-count line itself.

This commit extends and simplifies the test
`rpl.rpl_read_new_relay_log_info` to `main.rpl_new_info` so it
* Checks this detail to remind future changes of this type of mistake.
* Covers `@@master_info` as well.
* Covers the refactor’s buggy format as a downgrade/revert test.

While here, this commit also includes a new-format version
of MDEV-38020’s test to double as the value read check.

Reviewed-by: Brandon Nesterenko <[email protected]>
b97426350224...
b97426350224c7e5313ca6e18059ba095417139a
Rex Johnston
MDEV-35673 outer-reference characterization tests and the execute_various_ways harness (1/3)

Introduce main.outer_reference: labelled test cases exercising outer
references resolved through view merges, derived-table merges, CTEs,
semi-join conversions, unions, and GROUP BY/ORDER BY subqueries.

Each case is run through main/execute_various_ways.inc, which executes
the query six ways: directly, as a prepared statement executed twice,
wrapped in a derived table, in a view, in a CTE, and in a stored
procedure called twice.  Beyond the visible (recorded) output, the
harness pipes every method through a fresh mysql client session
(include/evw_capture.inc), isolates the output of the *second*
execution for the PS/SP methods, and asserts row-for-row equality of
all six methods with --diff_files.

This commit contains only the cases that already return consistent,
correct results: it documents current behaviour.  The remaining cases
are added by the commits that fix them.

This commit was prepared with Claude Code: it classified each
execute_various_ways group of the original MDEV-35673 test file against
the base tree (one mtr test per group) and selected for this commit the
80 groups whose behaviour is already correct, and drafted this commit
message.
b22511a90479...
b22511a9047951ab6190d01be36fddd2cfbf0b10
Rex Johnston
MDEV-30073 Wrong result on 2nd execution of PS for query with NOT EXISTS

Summary: Items of type Item_direct_view_ref which are reverted with the
change_item_tree mechanism are involved in permanent optimizer
transformations.  This commit ensures that items involved in these
permanent transformations are created during the first execution
and re-used for subsequent executions.

Queries affected by this bug are numerous, but will always involve
1) 2nd execution of a prepared statement or procedure
2) a permanent transformation, such as a semi-join optimization

Detail:

Consider this run as a prepared statement
SELECT * FROM t1
  WHERE EXISTS
  (
    SELECT dt.a FROM
      (
        SELECT t2a as a, t2b as b FROM t2
      ) dt
      WHERE dt.b = t1a
  )

During name resolution of field dt.b (in the where clause) we end
up calling find_field_in_view()/.../create_view_field().
This is responsible for creating a wrapper around the found Item
(Item_field*)`test`.`t2`.`t2b`
While this Item_direct_view_ref representing 'dt.b' is allocated on
Statement (permanent) memory the change is registered to be reversed
at the end of statement execution.  This is odd and contrary to the
permanent nature of this transformation.

Item::exists2in_processor() is called during the preparation in the
first execution.
We transform the query from
select * from t1 where
exists
(
  select `test`.`t2`.`t2b` from
    (
      select `test`.`t2`.`t2a` AS `a`,`test`.`t2`.`t2b` AS `b` from `test`.`t2`
    ) `dt`
    where `test`.`t2`.`t2b` = `test`.`t1`.`t1a`
    limit 1
)

select * from t1 where
`test`.`t1`.`t1a` in
(
  select `test`.`t2`.`t2b` from
    (
      select `test`.`t2`.`t2a` AS `a`,`test`.`t2`.`t2b` AS `b` from `test`.`t2`
    ) `dt`
    where 1
)

later, the optimizer merges the derived table dt into it's parent

select * from t1 where
`test`.`t1`.`t1a` in
(
  select `test`.`t2`.`t2b` from t2 where 1
)

then this is transformed into a semi-join

select t1.* from t1 semi join t2 on t1a = t2b

At the end of the first execution, the item t2b above is reverted to
dt.b.  During the subsequent name resolution of dt.b, it is resolved
t2a, and the semi-join executed corresponds to

select t1.* from t1 semi join t2 on t1a = t2a

causing a different result set.

Initial Author: Igor Babaev
Reformatted and refactored by: Rex Johnston ([email protected])

Add assert to ensure Item_direct_view_refs are not allocated on
the 2nd execution.

Notes:
Item_exists_subselect implicit LIMIT 1 no longer present during prepare
phase

The find_order_in_list save/reuse is safe: every ORDER reaching it comes
from add_to_list (initialized, sql/sql_parse.cc) or copy-constructed
from those (group_concat, window copies). add_proc_to_list ORDERs are
uninitialized but only reach setup_new_fields, which uses find_item_in_list
directly (~sql/sql_select.cc:27694). Saved select_item points into
select_lex->item_list nodes in statement memory so stable across executions.
b0b59cc7ee32...
b0b59cc7ee32ff3ea2b6b310e80c0871691e332c
Georg Richter
Merge branch '3.3' into 3.4
aea9f9572869...
aea9f957286922243a86d91244526b256eb3da8c
Vladislav Vaintroub
Fix DBUG_ASSERT in my_virtual_mem_protect
ac3f338b3d02...
ac3f338b3d02e2944305e6b6296b0413ad5e592c
ParadoxV5
Test for MDEV-39788

MDEV-39788 found that the recent refactor on the `main` (now 12.3)
branch missed the (inconsistent) detail that, unlike `relay-log.info`,
`master.info`’s line count _includes_ the line-count line itself.

This commit extends and simplifies the test
`rpl.rpl_read_new_relay_log_info` to `main.rpl_new_info` so it
* Checks this detail to remind future changes of this type of mistake.
* Covers `@@master_info` as well.
* Covers the refactor’s buggy format as a downgrade/revert test.

While here, this commit also includes a new-format version
of MDEV-38020’s test to double as the value read check.

Reviewed-by: Brandon Nesterenko <[email protected]>
a04215f61d9d...
a04215f61d9d028799c1194f969e5c6c3c785c98
Rex Johnston
MDEV-35673 stable outer-reference resolution across executions (2/3)

Split from MDEV-32294, discovered while inspecting how
Item_subselect::used_tables_cache is recalculated across the 1st and 2nd
executions of a prepared statement.

Name-resolution permanence:
- Preserve Item_field::depended_from across executions and use it in
  fix_fields/fix_outer_field instead of re-running the outward search,
  so 2nd-execution resolution is stable.
- find_field_in_tables: wrap a HAVING outer reference in an Item_ref
  during name resolution (previously done only in
  Item_field::fix_outer_field, now shared via
  fix_field_reference_to_having()), fixing a marked_for_read()
  assertion on queries such as
    SELECT 1 FROM (SELECT a FROM t1) b HAVING (SELECT b.a)=1
- create_view_field: resolve view-field substitutions against
  current_select and allocate them on statement memory.

Bookkeeping consumed by the next commit:
- Maintain SELECT_LEX::outer_references_resolved_here, a
  statement-memory list of the outer references resolved in each
  select_lex (relies on MDEV-30073 so these are not freed at end of PS
  execution), populated in st_select_lex::mark_as_dependent and kept
  correct across derived/semi-join merges (merged_into, nest_level /
  nest_level_base maintenance, select_update_base_processor).
  Item_subselect::recalc_used_tables() itself is rewritten in the next
  commit; until then the 2nd-execution guard from MDEV-30073 remains in
  Item_subselect::update_used_tables(), so re-executions run on the
  used_tables_cache computed by the first execution.

Ban EXPLAIN EXTENDED under the mtr --ps-protocol (warning output differs
because some select_transformers no longer run during PREPARE).

Remove select,ps.rdiff / select_jcl6,ps.rdiff / select_pkeycache,ps.rdiff:
the doubled "resolved in SELECT #1" notes they recorded no longer appear
under --ps-protocol.

main.union: the MDEV-29022 queries (UNION ordered by scalar subqueries
referencing the union columns by alias) are temporarily disabled: with
the interim used_tables handling they return misordered rows on the 2nd
execution under --ps-protocol.  Re-enabled by the next commit, which
fixes them.

main.subselect_mat_cost_bugs: the derived-table query whose correlated
WHERE subquery produces two 'Truncated incorrect DECIMAL value'
warnings loses those warnings on the 2nd execution under --ps-protocol
at this commit; its warnings are disabled here and re-enabled by the
next commit, which fixes the discrepancy.

Tests: extend main.outer_reference with the cases fixed by this commit
(view/derived/CTE-merged outer references, GROUP BY/ORDER BY subqueries,
MDEV-32297, MDEV-6054).

This commit was prepared with Claude Code: it partitioned the original
MDEV-35673 commit empirically (building and running the full SQL-layer
suites, both protocols, at each candidate boundary), verified that this
intermediate state is green apart from the two documented cases above,
moved the rdiff removals here from MDEV-40465 where they had gone stale,
and drafted this commit message.
8c896e0ef045...
8c896e0ef045e173ad0e7b25e3dd10e527664334
Rucha Deodhar
MDEV-40127: Server hangs when setting NEW=OLD on a multi-row table

Analysis:
m_fields was keeping old fields around across executions instead of
being cleared, causing stale state and hangs/crashes on re-execution.

Fix:
Clear m_fields in cleanup().
85c322f70e47...
85c322f70e477c5a7bd42c8344754d9335e56f58
Georg Richter
CONC-842: Fix heap buffer over-read in mthd_my_read_rows

A security vulnerability was identified in mthd_my_read_rows() where incoming
field length prefixes ('len') were validated only against the destination buffer
boundary ('end_to'), but not against the remaining source network packet buffer
('end_cp').

Because 'end_to' includes additional slack allocation bytes intended for field
NUL-terminators, a crafted packet with an inflated field length could bypass
destination checks, causing memcpy() to read out-of-bounds memory past 'end_cp'.

Fix this by introducing two validation steps:
1. Pre-check (cp >= end_cp): If the network buffer is exhausted before reading
  a field length byte (e.g. 8-field packet with fields = 9 due to extended
  type info), safely set remaining field pointers to NULL without reading
  out-of-bounds or throwing CR_MALFORMED_PACKET.
2. Post-check (len > end_cp - cp): Verify 'len' does not exceed remaining
  source packet bytes before executing memcpy(). Abort with
  CR_MALFORMED_PACKET if exceeded.
76a36bc8f1a4...
76a36bc8f1a4e869f55bb2a8655b0cd53d308844
Rex Johnston
MDEV-35673 rewrite Item_subselect::recalc_used_tables() (3/3)

Item_subselect::used_tables_cache was computed from upper_refs, a list
of Ref_to_outside snapshots taken at the first fix_fields().  Those
snapshots record the select the reference resolved in at that moment;
view merges, derived-table merges and semi-join conversions performed
later leave them pointing into merged-away selects, and they cannot be
rebuilt on re-execution.  The stale walk mis-classifies references, so
a correlated subquery can be treated as constant/uncorrelated.

Visible effects fixed here:
- server crash (SIGSEGV in sub_select) on plain execution of
    ( SELECT a c28 FROM t0 LIMIT 5 )
      ORDER BY ( SELECT c28 FROM t0 LIMIT 1 );    (MDEV-32766)
- UNION ... ORDER BY (scalar subquery referencing a union column by
  alias) returning misordered rows on the 2nd execution of a prepared
  statement (main.union, MDEV-29022 queries re-enabled here).

recalc_used_tables() now computes the map from
SELECT_LEX::outer_references_resolved_here (populated by the previous
commit and kept correct across merges), classifying each reference with
item_belongs_to()/Field_fixer against the merged_into chain.

With recalculation now valid on every execution:
- Item_subselect::cleanup() clears used_tables_cache and the FIXED
  flag, so each execution recomputes rather than reusing the previous
  execution's map;
- the temporary 2nd-execution guard in
  Item_subselect::update_used_tables() (from MDEV-30073) is removed;
- Item_subselect::mark_as_dependent() no longer builds Ref_to_outside
  entries during PS context analysis (upper_refs is no longer the
  source of used_tables_cache);
- Item_direct_view_ref::used_tables() returns 0 for a not-yet-fixed
  item instead of asserting, as recalculation can now run while items
  are being re-fixed.

main.win: the MDEV-18431 query (window function + correlated subquery
in one select-list expression) reads a stale used_tables_cache in
split_sum_func at re-execution and returns wrong results on the 2nd
execution under --ps-protocol; it is run with --disable_ps_protocol at
this commit.  The next commit (MDEV-40465) recomputes used_tables in
setup_fields before split_sum_func, fixes this, and removes the
wrapper to demonstrate it.

main.subselect_mat_cost_bugs: the warnings disabled by the previous
commit are re-enabled; the 2nd execution produces them again.

Tests: the remaining main.outer_reference case (MDEV-32766) is added.

This commit was prepared with Claude Code: it isolated the rewrite plus
its activation as the minimal unit that cannot be split further (any
intermediate state returns wrong results on re-execution), confirmed the
MDEV-32766 crash pre-exists on an unpatched 10.11 build, and drafted this
commit message.
68e7fb2662ac...
68e7fb2662accaba7094f8ef35894206c2e70128
Rucha Deodhar
MDEV-40124: Assertion `m_sp == m_thd->spcont->m_sp' failed virtual
Item *Item_splocal::this_item(), UBSAN : member call on null pointer of
type 'Sp_rcontext_handler' in sql/item.cc

Analysis:
Comparing trigger row objects (IF NEW = OLD) calls cmp_row_type(),
which uses element_index(i). Item_trigger_row was missing its own
element_index() override, falling back to Item_splocal's version
and crashing/asserting on local context lookup.

Fix:
Override element_index(i) in Item_trigger_row to return
m_fields.elem(i) directly.
641d82d891f6...
641d82d891f6f0e9288c79642ab0c94b4ca75f2d
Vladislav Vaintroub
fix SYS_VAR_READONLY test case on Windows
5d53e0392e72...
5d53e0392e728e1fdb85e5c9264f05c40afedd44
ParadoxV5
Cherry-pick MDEV-40366
5ab1e3002170...
5ab1e300217090b91cf8ca5767087ee41337a20b
Daniel Black
Remove no_valgrind_without_big.inc from *C* include dir

The identical file is in mysql-test/include where it is used.
52f44d12962b...
52f44d12962bb93150ab68252be6f3f707169def
Georg Richter
CONC-843: Backport fix for crash from 3.4 branch

If an unknown type was returned from server (e.g. MYSQL_TYPE_VECTOR)
client has to throw an error instead of crashing
4fcc29b01891...
4fcc29b018916a5d5fe6edc66408b160b2249d3b
Rex Johnston
MDEV-35673 outer-reference characterization tests and the execute_various_ways harness (1/3)

Introduce main.outer_reference: labelled test cases exercising outer
references resolved through view merges, derived-table merges, CTEs,
semi-join conversions, unions, and GROUP BY/ORDER BY subqueries.

Each case is run through main/execute_various_ways.inc, which executes
the query six ways: directly, as a prepared statement executed twice,
wrapped in a derived table, in a view, in a CTE, and in a stored
procedure called twice.  Beyond the visible (recorded) output, the
harness pipes every method through a fresh mysql client session
(include/evw_capture.inc), isolates the output of the *second*
execution for the PS/SP methods, and asserts row-for-row equality of
all six methods with --diff_files.

This commit contains only the cases that already return consistent,
correct results: it documents current behaviour.  The remaining cases
are added by the commits that fix them.

This commit was prepared with Claude Code: it classified each
execute_various_ways group of the original MDEV-35673 test file against
the base tree (one mtr test per group) and selected for this commit the
80 groups whose behaviour is already correct, and drafted this commit
message.
4d6ab8f22dc4...
4d6ab8f22dc48e9990d97ca36fbd8952d60d8ea6
ParadoxV5
Test for MDEV-39788

MDEV-39788 found that the recent refactor on the `main` (now 12.3)
branch missed the (inconsistent) detail that, unlike `relay-log.info`,
`master.info`’s line count _includes_ the line-count line itself.

This commit extends and simplifies the test
`rpl.rpl_read_new_relay_log_info` to `main.rpl_new_info` so it
* Checks this detail to remind future changes of this type of mistake.
* Covers `@@master_info` as well.
* Covers the refactor’s buggy format as a downgrade/revert test.

While here, this commit also includes a new-format version
of MDEV-38020’s test to double as the value read check.

Reviewed-by: Brandon Nesterenko <[email protected]>
4c7b53f997fa...
4c7b53f997fa3858a0ba5f09028921960ba32ad5
Aleksey Midenkov
MDEV-38854 Assertion table->vers_write fails upon ODKU into table with versioned column

In MDEV-25644 vers_check_update() sets vers_write to false in case it
returns false. It is ok for UPDATE but is not correct for ODKU is bulk
insert requires vers_write on next tuple.

The fix return vers_write value back when vers_check_update() and
related vers_insert_history_row() are done in ODKU.
3d5630849798...
3d563084979812795a70863e5abf2f584afea9e7
Rex Johnston
MDEV-35673 rewrite Item_subselect::recalc_used_tables() (3/3)

Item_subselect::used_tables_cache was computed from upper_refs, a list
of Ref_to_outside snapshots taken at the first fix_fields().  Those
snapshots record the select the reference resolved in at that moment;
view merges, derived-table merges and semi-join conversions performed
later leave them pointing into merged-away selects, and they cannot be
rebuilt on re-execution.  The stale walk mis-classifies references, so
a correlated subquery can be treated as constant/uncorrelated.

Visible effects fixed here:
- server crash (SIGSEGV in sub_select) on plain execution of
    ( SELECT a c28 FROM t0 LIMIT 5 )
      ORDER BY ( SELECT c28 FROM t0 LIMIT 1 );    (MDEV-32766)
- UNION ... ORDER BY (scalar subquery referencing a union column by
  alias) returning misordered rows on the 2nd execution of a prepared
  statement (main.union, MDEV-29022 queries re-enabled here).

recalc_used_tables() now computes the map from
SELECT_LEX::outer_references_resolved_here (populated by the previous
commit and kept correct across merges), classifying each reference with
item_belongs_to()/Field_fixer against the merged_into chain.

With recalculation now valid on every execution:
- Item_subselect::cleanup() clears used_tables_cache and the FIXED
  flag, so each execution recomputes rather than reusing the previous
  execution's map;
- the temporary 2nd-execution guard in
  Item_subselect::update_used_tables() (from MDEV-30073) is removed;
- Item_subselect::mark_as_dependent() no longer builds Ref_to_outside
  entries during PS context analysis (upper_refs is no longer the
  source of used_tables_cache);
- Item_direct_view_ref::used_tables() returns 0 for a not-yet-fixed
  item instead of asserting, as recalculation can now run while items
  are being re-fixed.

main.win: the MDEV-18431 query (window function + correlated subquery
in one select-list expression) reads a stale used_tables_cache in
split_sum_func at re-execution and returns wrong results on the 2nd
execution under --ps-protocol; it is run with --disable_ps_protocol at
this commit.  The next commit (MDEV-40465) recomputes used_tables in
setup_fields before split_sum_func, fixes this, and removes the
wrapper to demonstrate it.

main.subselect_mat_cost_bugs: the warnings disabled by the previous
commit are re-enabled; the 2nd execution produces them again.

Tests: the remaining main.outer_reference case (MDEV-32766) is added.

This commit was prepared with Claude Code: it isolated the rewrite plus
its activation as the minimal unit that cannot be split further (any
intermediate state returns wrong results on re-execution), confirmed the
MDEV-32766 crash pre-exists on an unpatched 10.11 build, and drafted this
commit message.
39569c6606dc...
39569c6606dced86d96605bf052497d9f7163bc8
KhaledR57
MDEV-37859 mysqltest hex() fails on string arguments

func_hex() passed every argument through convert_base_helper(), which
parses the argument as a base 10 number. A string argument therefore
died with "invalid number 'abc' for base 10" instead of being converted.

HEX() is the only one of the base conversion functions that accepts a
string. In the server BIN() and OCT() are built as Item_func_conv() with
fixed bases and are numeric only, while HEX() has a dedicated Item with
a separate string path, because HEX() is the counterpart of UNHEX() and
has to serialise bytes.

Dispatch on the argument type: numeric arguments keep the existing
CONV(N, 10, 16) behaviour, string arguments are converted byte by byte
with String::set_hex(), which is the same call the server uses in
Item_func_hex::val_str_ascii_from_val_str().
30ef29ffe93a...
30ef29ffe93ad2f59f4d7b4824e53b85bec39ee0
ParadoxV5
Cherry-pick MDEV-40365

Merge conflict with MDEV-30128 resolution
2f7feb0bbb36...
2f7feb0bbb36b65b007e15682d29d055655569b8
rusher
[CONC-786] add infer to CI
07213c0475a9...
07213c0475a91f0b2f0d6b21bd9e39daf59895fb
Daniel Black
MDEV-39113 MSAN/ADDR addr2line stack resolver detrimental

MSAN/ASAN test environment, the addr2line was so high in memory
utilization that it was the pick of the OOM killer to resolve the OOM
situation. Once this occurred there wasn't a saved core or gdb backtrace
of the core to resolve the issue.

To resolve this, make stack-trace default to 0 (off) for the addr2line
base implementation under memory sanitizer and address sanitizer.

MariaDB-backup also forces the enabling of stack-trace. Disabling this
unconditionally reduces the risk of a user operational impact if a
lengthy stack trace starting in a mariadb-backup critical locked period.

The mysqld--help test now excludes the stack-trace as its result is
environment dependant. The "Defaults to..." output for suppressed
variables, currently only stack-trace, is excluded.

Since thread-stack is an excluded varable, the ubsan/asan exclusions
from commits dfa6fba9595a and dfa6fba9595a aren't required.
067b7404a349...
067b7404a349b01d186340b582f29f7e4d710505
Rex
MDEV-40465 table map consulted during setup fields on unfixed items

In setup_fields() we call item->update_used_tables() before split_sum_func
so that used_tables() is not consulted before the caches are set up on the
2nd execution of a prepared statement.  This fixes a 1st/2nd execution
main.win --ps-protocol failure noted in the previous commit (the window
function's correlated argument looked constant to split_sum_func2, so no
Item_ref into the window temp table was created on re-execution).

That recalculation exposes items whose caches are read while still being
(re)built, so add the guards it now depends on:
- Item_field::used_tables(): return 0 when field / field->table is not
  yet set, instead of dereferencing a null pointer.
- Item_func::fix_fields(): reset used_tables_cache/const_item_cache at
  entry (assignment) instead of asserting they are already clear, so a
  re-fix is idempotent.

The --disable_ps_protocol wrapper placed around the main.win
MDEV-18431 query by the previous commit is removed: that query now
returns identical results on the 1st and 2nd execution.

Claude Code relocated this commit's rdiff removals to an earlier commit
of the series (where the recorded differences actually disappear) and
updated this message accordingly.
061301bea9b1...
061301bea9b1eca19167d8b02e7ef15c1720dff3
Rex
MDEV-40465 table map consulted during setup fields on unfixed items

In setup_fields() we call item->update_used_tables() before split_sum_func
so that used_tables() is not consulted before the caches are set up on the
2nd execution of a prepared statement.  This fixes a 1st/2nd execution
main.win --ps-protocol failure noted in the previous commit (the window
function's correlated argument looked constant to split_sum_func2, so no
Item_ref into the window temp table was created on re-execution).

That recalculation exposes items whose caches are read while still being
(re)built, so add the guards it now depends on:
- Item_field::used_tables(): return 0 when field / field->table is not
  yet set, instead of dereferencing a null pointer.
- Item_func::fix_fields(): reset used_tables_cache/const_item_cache at
  entry (assignment) instead of asserting they are already clear, so a
  re-fix is idempotent.

The --disable_ps_protocol wrapper placed around the main.win
MDEV-18431 query by the previous commit is removed: that query now
returns identical results on the 1st and 2nd execution.

Claude Code relocated this commit's rdiff removals to an earlier commit
of the series (where the recorded differences actually disappear) and
updated this message accordingly.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Tue 28 Jul 2026 07:24:07 (UTC)