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
feeee870ceee...
feeee870ceee9266db57b681c7cd95e89115b95e
Dave Gosselin
MDEV-38692: COALESCE() on NATURAL FULL JOIN result sets

FULL JOIN yields result sets with columns from both tables participating in
the join (for the sake of explanation, assume base tables).  However,
NATURAL FULL JOIN should show unique columns in the output.

Given the following query:
  SELECT * FROM t1 NATURAL JOIN t2;
transform it into:
  SELECT COALESCE(t1.f_1, t2.f_1), ..., COALESCE(t1.f_n, t2.f_n) FROM
    t1 NATURAL JOIN t2;

This change applies only in the case of NATURAL FULL JOIN.  Otherwise,
NATURAL JOINs work as they have in the past, which is using columns
from the left table for the resulting column set.
fed2ad51323e...
fed2ad51323e3a741ca6638fd4aee8b333232f4e
Dave Gosselin
MDEV-39605: Assertion `!tbl->nested_join || tbl->sj_on_expr` failed

simplify_joins keeps a nested join intact when it contains
FULL JOIN tables and has siblings in its parent join list.
Flattening would let the optimizer interleave outside tables
between the FULL JOIN tables, which the null complement
algorithm cannot handle.  Such a nest carries neither on_expr
nor sj_on_expr and reaches table elimination, where we hit an
assertion which required one or the other.

Replace the assertion with a recursion into the nest.  Pass
on_expr=NULL so the nest itself is not eliminated, and set
all_eliminated to FALSE so an enclosing call does not eliminate
the parent.  Inner LEFT JOIN tables can still be eliminated by
the recursive call.
fc479d237a6e...
fc479d237a6e6e7a1abde1499edf58c144aa48f7
Vladislav Vaintroub
x
fb8fc734a724...
fb8fc734a7248f9e89448945bfd1e2ebd866ed99
Dave Gosselin
MDEV-37932: Parser support FULL OUTER JOIN syntax

Syntax support for FULL JOIN, FULL OUTER JOIN, NATURAL FULL JOIN, and
NATURAL FULL OUTER JOIN in the parser.

While we accept full join syntax, such joins are not yet supported.
Queries specifying any of the above joins will fail with
ER_NOT_SUPPORTED_YET.
fafcaa81f983...
fafcaa81f9839684b8f98e0824568634b2960420
Daniel Bartholomew
bump the VERSION
f6adc063622d...
f6adc063622d7a83fd2c87b2a72b19818747bbbc
Dave Gosselin
Remove the unused AGGR_OP::flush_record method
f08889f1008c...
f08889f1008ce4e781bc397c8da186753c640e97
Dave Gosselin
MDEV-39715: semijoin nest under a FULL JOIN triggers assertion

When an IN-subquery in the ON clause of a JOIN to a FULL JOIN nest
becomes a semijoin, the new semijoin nest is placed inside the FULL JOIN
nest.  Normally that enclosing nest would be flattened, but a FULL
JOIN nest is not flattenable, so the semijoin nest remains.

check_interleaving_with_nj used to skip sj-nests when updating
counters, so every semijoin inner table also bumped the enclosing
nest's counter.  With two inner tables and two FULL JOIN tables, the
enclosing nest's counter went to 4 against a limit of 3 and the
assertion fired.

Count the semijoin nest as one child of its parent.  Bump the semijoin
nest's own counter on each semijoin inner table, and only bump the
parent once the semijoin nest is fully placed.  restore_prev_nj_state
is changed the same way for backtracking.
ed8404a73f93...
ed8404a73f93e79aff7227bb4560a44cbfdb5d1c
Hemant Dangi
MDEV-39721: wsrep_notify.cc: reject shell-unsafe characters in joiner-supplied member fields

Issue:
wsrep_notify_status() interpolated members[i].name() (the peer's
wsrep_node_name) and members[i].incoming() verbatim into a command
string that is then executed via 'sh -c' by wsp::process. A peer
joining the cluster with shell metacharacters in its wsrep_node_name
or wsrep_node_incoming_address caused arbitrary commands to run on
every cluster member that had wsrep_notify_cmd configured.
MDEV-39413 introduced safe() for the same threat class in the SST
scripts but did not cover the C++ wsrep_notify path.

Solution:
Validate each substituted field against a narrow whitelist before
interpolating. Node name allows alnum and -_. ; node address
additionally allows :[]/ for host:port and [ipv6] forms. On bad
input the notification is skipped with an error log instead of
forwarding the unsafe value to sh -c.
d8dd579dd01e...
d8dd579dd01e6a62ee02454d41936fdecab81057
Vladislav Vaintroub
x
d5dd63fd035d...
d5dd63fd035d14cddb690bfe8ac40bef0c5673ca
Dave Gosselin
MDEV-39713: Propagate dep_tables for FULL JOIN with constant ON

A FULL JOIN with a constant ON expression did not encode
the outer table dependency in the on_expr because the
constant references no tables.  The enclosing nest's
dep_tables, however, still carries that dependency, so
propagate it.
d32d21119c66...
d32d21119c6694882ba0f72a621a11f294233ac3
Dave Gosselin
MDEV-39560: Assertion `found_tables > 0' failed

Ignore JOIN_ORDER hints that force FULL JOINs to the inner
side of other JOINs.

A FULL JOIN must be placed before any table outside of the FULL JOIN
in the join order; FULL JOINs are not allowed on the inner side of an
enclosing LEFT or RIGHT JOIN.  Prevent the user from supplying a
JOIN_ORDER() hint that otherwise forces this invalid order, and emit a
warning.  When we implement phase 3 of FULL JOIN support, this
restriction will be relaxed.
c8a145708e2c...
c8a145708e2c92e54dd30e6411247229db074080
Dave Gosselin
MDEV-39663: Assertion `found_tables > 0' failed

Early on in FULL OUTER JOIN development, it seemed prudent to
attach the ON condition to both tables during FULL OUTER JOIN
parsing, because either table in the join could be considered
the inner or outer table, depending on perspective.  This
decision ended up complicating both simplify_joins and the
FULL JOIN rewrites to other join types, as well as dependent
table propagation during make_join_statistics.  Dependent
table propagation was not correct because both tables in the
FULL JOIN carried the ON expression which confused
make_join_statistics.

We could update make_join_statistics to propagate dependent
tables for both sides of a join, but that's essentially changing
the mainstream join processing path for the sake of one case
case.  Instead, just stop attaching the ON condition to both
tables in a FULL OUTER JOIN, which simplifies the FULL JOIN
rewrites and relies on pre-existing table dependency propagation
in make_join_statistics.
c04473cd77cf...
c04473cd77cff10ee43f89fa7e929f1091146ea9
Dave Gosselin
MDEV-39619: Compute FULL JOIN nest tables recursively

compute_full_join_nest_tables built the bitmap of tables that must
stay adjacent in the join order by iterating leaf_tables and OR'ing in
each enclosing nest's direct_children_map.  That missed FULL JOIN
tables that are themselves a nest of inner joins.  With those tables
missing from full_join_nest_tables, the adjacency restriction in
get_allowed_nj_tables let the optimizer descend into an inner nest
whose remaining tables depended on a table outside it, triggering the
found_tables>0 assertion in best_extension_by_limited_search.

Replace the leaf walk with a recursive walk over top_join_list.  For
every TABLE_LIST flagged JOIN_TYPE_FULL, OR in its
nested_join->used_tables (for a nest) or table->map (for a base
table), and recurse into every nested_join so a FULL JOIN table that
is itself a nest contributes all of its leaf tables.
b2050fdb4a87...
b2050fdb4a8776422baf01a41bf86845994edb97
Sergei Golubchik
strengthen safe() in wsrep_sst_common, just in case
9b9bcdee2e76...
9b9bcdee2e76305c8bf4e682b83eaa83bf6539de
Dave Gosselin
MDEV-39569: Skip FULL JOIN rewrite to inner side of an outer join

Prevent simplify_joins from rewriting a chained FULL JOIN into a query
where a FULL JOIN could end up on the inner side of another outer
join.  Of course, this means that we will have a null complement pass
that the rewritten query would have avoided.  Once we support FULL
JOINs on the inner side of outer joins, in phase 3, then we can relax
this constraint.
9a52192c0b51...
9a52192c0b518b0b5455bafe3906606ff8a73514
Vladislav Vaintroub
MDEV-39719 Fix memory allocation errors on Windows ARM64 CI

Reduce the default max size from 8TB to 128GB. on ARM64, allocating
multiple huge areas (like CI does, for multiple processes) can result in
exhaustion of internal kernel memory. Presumably non-paged pool, used
for page translation tables (this info is provided by AI, can't verify).
93049da77c62...
93049da77c62158b7f591fb668ec1c9d1e4725bd
Vladislav Vaintroub
y
9126c6319a41...
9126c6319a41d1e0704be70d8c49668edc04cf02
Dave Gosselin
MDEV-39618:  Assertion failed

In run_fj_null_complement_pass, the FULL JOIN null complement pass
called ha_end_keyread() on the right table to switch from index access
before rescanning, but never restored keyread after it finished; so
do that.
8f29dce6eb80...
8f29dce6eb804b85e389f3f159045847a0c13cb5
Dave Gosselin
In end_send, grab the list of fields from the prior join_tab if available

Allocate the full_join_duplicate_filter with operator new.  Add a comment
to the assertion and condense a couple of conditionals together.
8c007d6bf807...
8c007d6bf8070c803e2e5b7ce4652a3d5f29aa19
Vladislav Vaintroub
x
88bb1f425b6f...
88bb1f425b6fbda04a50810212ab724ee8aaa38d
Dave Gosselin
MDEV-38136: Prevent elimination of tables in a FULL OUTER JOIN

Prevent elimination of tables participating in a FULL OUTER JOIN during
eliminate_tables as part of phase one FULL OUTER JOIN development.

Move the functionality gate for FULL JOIN further into the codebase: convert
LEX::has_full_outer_join to a counter so we can see how many FULL JOINs
remain which makes the gate work correctly after simplify_joins and
eliminate_tables are called.

Fixes an old bug where, when running the server as a debug build and in
debug mode, a null pointer deference in
Dep_analysis_context::dbug_print_deps would cause a crash.
80489d27e355...
80489d27e35557a51593492d75b4a03f7afe7381
Dave Gosselin
MDEV-39014: FULL JOIN Phase 2

In phase 1, FULL [OUTER] JOIN was only supported when simplify_joins()
could rewrite it into an equivalent LEFT, RIGHT, or INNER JOIN based
on NULL-rejecting WHERE predicates.  Queries that could not be
rewritten raised ER_NOT_SUPPORTED_YET.  (Phase 1 was not released.)

This commit removes that restriction by adding proper support for FULL
JOIN by executing a 'LEFT JOIN pass' that emits matched rows and left
null-complemented rows, then a second "null-complement" pass which
rescans the right table to emit null-complement rows that were never
matched.

FULL JOIN supports nested joins on the left of the FULL JOIN,
NATURAL FULL JOIN, semi-joins, CTEs / derived tables (kept
materialized when they participate in a FULL JOIN), prepared
statements, stored procedures, and aggregates.  Examples:

  SELECT * FROM (d1 FULL JOIN d2 ON d1.a = d2.a)
              FULL JOIN t3 ON d1.a = t3.a;

  SELECT * FROM t1 NATURAL FULL JOIN t2;

  SELECT * FROM t1 INNER JOIN t2 FULL JOIN t3 ON t1.a = t3.a;

  PREPARE st FROM
    'SELECT COUNT(*) FROM t1 FULL JOIN t2 ON t1.a = t2.a';

Limitations:
  - The join cache is disabled whenever a FULL JOIN is present, which
    can regress plans for large FULL JOINs compared to the rewritten
    cases.  A follow-up will re-enable it where safe.
  - Statistics and cost estimates for the null-complement pass have
    not been fully implemented; the optimizer may under- or
    over-estimate FULL JOIN costs in plans involving multiple
    FULL JOINs.  Again, a follow-up will optimize the cost calculations.
  - Optimizations for constant tables not fully supported.
  - Nested tables on the right side of a FULL JOIN are not yet supported.
7d086be762a0...
7d086be762a08c8d34e8fcb03814cf2222d03860
Vladislav Vaintroub
x
7911f7267c50...
7911f7267c5039efdae2407eb5a6b94a9fabdea7
Dave Gosselin
MDEV-37995: FULL OUTER JOIN name resolution

Allow FULL OUTER JOIN queries to proceed through name resolution.

Permits limited EXPLAIN EXTENDED support so tests can prove that the
JOIN_TYPE_* table markings are reflected when the query is echoed back by the
server.  This happens in at least two places:  via a Warning message during
EXPLAIN EXTENDED and during VIEW .frm file creation.

While the query plan output is mostly meaningless at this point, this
limited EXPLAIN support improves the SELECT_LEX print function for the new
JOIN types.

TODO: fix PS protocol before end of FULL OUTER JOIN development
78bc473197eb...
78bc473197eb1b6f0b39cccb422e3c628d406b8b
Dave Gosselin
FULL JOIN, straight_join and optimizer hint support

Previously the FULL JOIN tables had to come first in the join
order, before any other table.  They still have to stay next to
each other, but they can now appear before, after, or between
other tables in the FROM clause.

Update the JOIN_ORDER, JOIN_PREFIX, and JOIN_SUFFIX hint conflict
check to match.  The new check only rejects a hint when it would force
a non-FULL JOIN table to sit between two FULL JOIN tables, which is
the case that actually breaks the null-complement rescan.  It finds
this by computing the set of predecessors of FULL JOIN tables and the
set of successors of FULL JOIN tables, after the hint's dependencies
have been added, and rejects the hint when those sets overlap on a
non-FULL-JOIN, non constant table.
77582ad7175d...
77582ad7175d55dd02ae2b2ef924506939bb7b96
Vladislav Vaintroub
x
74ebfca23df6...
74ebfca23df650ddf64d488ceea937d62f78d297
Dave Gosselin
MDEV-38502: FULL OUTER JOIN get correct sargable condition

Fetches the ON condition from the FULL OUTER JOIN as the sargable condition.
We ignore the WHERE clause here because we don't want accidental conversions
from FULL JOIN to INNER JOIN during, for example, range analysis, as that
would produce wrong results.

GCOV shows that existing FULL OUTER JOIN tests exercise this new codepath.
6fb907b46437...
6fb907b46437bee84535b18df7c7146a5d842a06
bsrikanth-mariadb
MDEV-39412: parse error reading tabs in ranges

Note:
while reading from information_schema.optimizer_context one level of unescaping
is already done i.e. (\\t becomes \t or \\\\t becomes \\t)

w.r.t the MDEV, there are 2 problems: -

1.
When reading from the sql script file, json parser is not able to parse
the range value in json_read_value() from json_lib.c
"ranges": [
            "(b\t\t\t\t\t\t) <= (b) <= (b???????)"
          ],
mainly the \t\t stuff, and hence a warning.
It also stops loading the context into memory.
Since, a new table is created with empty data, and without context,
we get Impossible WHERE noticed after reading const tables

2.
There is unescaping call being made in read_string() from sql_json_lib.cc
while parsing of the context. With this \\t was becoming \t.
However, print_range() from opt_range.cc already does escaping of the values.
The value "b\t\t\t" was in fact produced as "\b\\t\\t\\t".
Later, we try to compare range values from the query and the context.

Here a mismatch is found because, in one case there is escaping,
and in the other case escaping got removed.

Solution
========
Since, there are 2 levels of unescaping being performed, 1. during sql
parse of the context from information_schema, and 2. during
read_string. So, we need to have 2 levels of escaping.

First is done in the dump_mrr_info_calls() - here
json_escape_to_string() is used.

Second is done at the end of store_optimizer_context(), for the entire
opt_context. Here a newly introduced function escape_json_for_sql_literal()
is used which does escaping only for backslash, and single quote.
6676a3caaa93...
6676a3caaa930e37b2888065f595e1f8b51c2160
Dave Gosselin
Make FULL JOIN work correctly when other tables sit beside it

A FULL JOIN produces its result in two stages.  The first stage walks
the joined tables like a LEFT JOIN, emitting every left row paired
with its matches on the right (or with NULLs if there were none).  The
second stage walks the right table again and emits the right rows that
never found a match, padded with NULLs on the left.

Until now the second stage ran exactly once per query, after the whole
first stage had finished.  That worked only when the FULL JOIN was the
entire query.  As soon as another table sat outside the FULL JOIN, the
result became wrong, because the "right rows with no matches" needed
to be paired with the outer table's rows just like the matched rows
were.  To avoid producing wrong answers, the optimizer was forced to
put FULL JOIN tables first.

This change moves the second stage so that it runs as part of the same
nested loop that produced the first stage's matches.  Each time the
outer loop advances to a new row, the right table is rescanned for its
unmatched rows, and those rows flow through the rest of the query
exactly the way ordinary join output does.

With the two stages now interleaved, the optimizer no longer has to
force the FULL JOIN to the front of the join order.  Tables outside
the FULL JOIN can sit on either side of it, and the FULL JOIN itself
only needs to stay together as one contiguous group.
606610c1e57e...
606610c1e57eac7394e6c4409e8b09620a896914
Dave Gosselin
MDEV-39607:  Segmentation fault in alloc_full_join_duplicate_filters

The count of JOIN_TAB instances passed to alloc_full_join_duplicate_filters
was the total count, including the constant tables.  But start_tab points
to the first JOIN_TAB after the constant tables, so it was walking off the
end of the JOIN_TAB instances in memory.  Just take the starting point from
the JOIN directly and include the constant tables (which we'll need to do
in phase 3 anyway).
57e4a63a8e32...
57e4a63a8e327baacc205d1b6d7577e4a9af3cab
Oleksandr Byelkin
make resalt the same for different platforms
418ae57946b0...
418ae57946b033f331617c94857d510d1f63a6d6
Dave Gosselin
RelWithDebInfo builds in buildbot could fail

The crash happened because we computed an incorrect stopping point
for the JOIN_TAB walk when finding the left-most JOIN_TAB for a
FULL JOIN in a bush child.  When inspecting bush children, the
eligible JOIN_TABs are those of the particular bush, so walk over
those.  Previously, we took the end point as JOIN::join_tab, which
was incorrect, causing the walk to go into arbitrary memory.
2f696153527a...
2f696153527a9ced4436893166988cec69c5bd93
Dave Gosselin
Remove unnecessary and unused 'top' parameter from simplify_joins.
256dde0a7747...
256dde0a77471ac8e3f85342ffaa4998cb8b5dc0
Dave Gosselin
Fixed a bug in simplify_joins which allowed a FULL JOIN nest to have
its tables flattened out of their nest, leading to a join ordering
problem and allowing the optimizer to interleave the outer table
into the join order incorrectly (possibly between FULL JOIN'd tables).

Disallow FULL JOIN on the right side of a left or right join and
prevent FULL JOIN on right in VIEWs.

Do not merge VIEWs that have a FULL JOIN in them and let simplify_joins
do any derived table merging as it relates to FULL JOINs.
233e284b458a...
233e284b458adf6fcdf19797341c10d90bdef3ed
Dave Gosselin
MDEV-38508: Constant table detection

If a table that's in a FULL OUTER JOIN is found to be a const
table, then don't allow the constant table optimization to
take place.

Later, when we support FULL OUTER JOIN on the inner side of
other join types then we may be able to relax this restriction.
22f1c77ab3d4...
22f1c77ab3d408a59ccb1a2035798358dd5d7966
Dave Gosselin
MDEV-37933: Rewrite [NATURAL] FULL OUTER to LEFT, RIGHT, or INNER JOIN

Rewrite FULL OUTER JOIN queries as either LEFT, RIGHT, or INNER JOIN
by checking if and how the WHERE clause rejects nulls.

For example, the following two queries are equivalent because the
WHERE condition rejects nulls from the left table and allows matches
in the right table (or NULL from the right table) for the remaining
rows:

  SELECT * FROM t1 FULL JOIN t2 ON t1.v = t2.v WHERE t1.v IS NOT NULL;
  SELECT * FROM t1 LEFT JOIN t2 ON t1.v = t2.v;

  SELECT * FROM t1 FULL JOIN t2 ON t1.v = t2.v WHERE t1.a=t2.a;
  SELECT * FROM t1 INNER JOIN t2 ON t1.v = t2.v WHERE t1.a=t2.a;
21d2802b26a9...
21d2802b26a9576c89e3a6ba4214e3415cdf59b6
Dave Gosselin
MDEV-38502: FULL OUTER JOIN get correct sargable condition

Move the temporary gate against FULL OUTER JOIN deeper into the
codebase, which causes the FULL OUTER JOIN query plans to have
more relevant information (hence the change).  In some cases, the
join order of nested INNER JOINs within the FULL OUTER JOIN changed.

Small cleanups in get_sargable_cond ahead of the feature work in
the next commit.
197f92bee02d...
197f92bee02d8e836f529f37625be69b83e7acbd
Sergei Golubchik
Merge branch '10.6' into 10.11
09d471f48ef0...
09d471f48ef09e8165eae7e29cb4c428b7482067
Dave Gosselin
all table names, aliases, view names, etc are now lowercase
BuildBot (0.8.9) working for the MariaDB project.
Page built: Sat 23 May 2026 15:49:04 (UTC)