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
fa2875bc6e03...
fa2875bc6e034b748f110a702f5be9ae5dd0426c
Oleksandr Byelkin
Merge branch 'bb-10.11-release' into bb-11.4-release
f485f93aed96...
f485f93aed963bedd03a373a00aad0dddfc435d3
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
e7f1470b2896...
e7f1470b28966aed7d31f6f51eefd536992ceba4
Sergei Golubchik
MDEV-39363 Logical Bug in `NOT ( ... XOR ... )` Evaluation with Implicit Type Conversion

for 0.1f val_int() is 0, val_bool() is 1.
dacd2a9b76a7...
dacd2a9b76a7c4a24e18fdcf2850231d2373205e
Oleksandr Byelkin
Merge branch 'bb-10.11-release' into bb-11.4-release
d0501281ecb0...
d0501281ecb025b0d3ccf72b2d7e3e9473705f35
Sergei Golubchik
MDEV-39481 ASAN error on malformed WKB polygon

let's make is difficult for wkb and len to desync
b66db0f23bd2...
b66db0f23bd253bfdcd8f475b017d49f36d05d9f
Marko Mäkelä
MDEV-32115: Log checkpoint race with wsrep_sst_method=rsync

Galera snapshot transfer (SST) using the default wsrep_sst_method=rsync
is prone to creating corrupted snapshots. The probability for this is
rather low and might only affect installations that include
ENGINE=InnoDB tables that contain FULLTEXT INDEX.

The function sst_disable_innodb_writes() aims to disable all InnoDB writes
during the time a snapshot transfer (SST) is in progress using the
default wsrep_sst_method=rsync.

The logic based on invoking log_make_checkpoint() almost works, except
for two things: We failed to ensure that fts_optimize_callback() has
stopped executing, and we did not block updates of the log checkpoint
header.

log_checkpoint_low(): Assert that writes to the log are allowed.

buf_flush_page_cleaner(): Do not try to advance the checkpoint while
wsrep_sst_method=rsync is in progress. This prevents the assertion
in log_checkpoint_low() from failing.

fts_optimize_pause(), fts_optimize_resume(): Pause and resume the
fts_optimize_callback().

sst_disable_innodb_writes(): Disable all background writers
before initiating the log checkpoint.

fts_optimize_callback(): Assert that wsrep_sst_method=rsync is not
active, and remove the previous incorrect attempt at fixing this race.
b307d88f66ec...
b307d88f66ec8863e13e06619d1af87aa2004fbe
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
aad585e4aed0...
aad585e4aed0444eb0306e9f4a98c26b561d23f6
Oleksandr Byelkin
Merge branch '10.6' into bb-10.11-release
a79ce0c550bc...
a79ce0c550bc3cdb5b319bf34170b9021f7cc3ed
Dave Gosselin
MDEV-37020: Derived table merge optimization does not work for delete and update

A derived table in a multitable DELETE or UPDATE was materialized
while a derived table in an equivalent query using a VIEW was merged.

The cause was a blanket guard in TABLE_LIST::init_derived added by
commit fe89df42686f.  That commit fixed a ROWNUM crash on VIEWs with
ORDER BY, but its derived table guard was wider than it needed to be.

Narrow that guard to the case when the derived table lives inside a
VIEW's body (the case when belong_to_view is set).  A derived table at
the top level of a multitable query will be merged, while a derived
nested table within a VIEW will be materialized.

Narrowing that guard exposes a separate latent bug.  The access check
in multi_update_check_table_access has a branch for VIEWs and another
for 'not VIEWs' which dereferences table->table->map.  A merged
derived table that is not a VIEW fits neither condition.  As is the
case in main.lock_multi_bug38499, when concurrent ALTER on the target
forces the prepared statement to be prepared again, table->table on
the merged derived table might be NULL and this leads to a crash.
Privileges for the underlying base tables are already checked by
multi_update_precheck, so multi_update_check_table_access now returns
early in its else branch when the input is a merged derived table.
9721c7786a77...
9721c7786a77c45dadc5c7ac5fb6465817ed3fda
Lawrin Novitsky
ODBC-492 SQLGetTypeInfo: Wrong COLUMN_SIZE for SQL_TYPE_TYPESTAMP

Specs say that column size for temporal types has to be length in chars for representation with
max possible precision. i.e. in case of MariaDB this is 26
Also other types have been corrected:
- SQL_TYPE_TIME for the same logic has to be 17. Event though ODBC type
  isn't supposed to have fractional part and hours value beyond 0-23
- SET and ENUM effective max length is ~65216
- TYPE_(W)VARCHAR is 65532

There were also some discrepences between values for ODBCv3 and ODBCv2
Enhanced existing test to check all these values.
  • codbc-alma8-aarch64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-alma9-aarch64: build linux-connector_odbc failed -  stdio
  • codbc-alma9-amd64: build linux-connector_odbc failed -  stdio
  • codbc-alma84-amd64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-bookworm-aarch64: build linux-connector_odbc failed -  stdio
  • codbc-bookworm-amd64: build linux-connector_odbc failed -  stdio
  • codbc-bullseye-aarch64: build linux-connector_odbc failed -  stdio
  • codbc-bullseye-amd64: build linux-connector_odbc failed -  stdio
  • codbc-jammy-amd64: build linux-connector_odbc failed -  stdio
  • codbc-noble-amd64-memcheck: build linux-connector_odbc failed -  stdiowarnings (4)
  • codbc-rhel8-aarch64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-rhel8-amd64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-rhel9-aarch64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-rhel9-amd64: build linux-connector_odbc failed -  stdiowarnings (1)
  • codbc-rocky8-aarch64: build linux-connector_odbc failed -  stdio
  • codbc-sles15-amd64: build linux-connector_odbc failed -  stdiowarnings (5)
  • codbc-windows: 'dojob SET TEST_DSN=odbc-3.1 SET TEST_DRIVER=odbc-3.1 SET TEST_PORT=3306 SET TEST_SCHEMA=odbcodbc-3.1 cd win32/test ctest --output-on-failure' failed -  stdio
96531691c18e...
96531691c18ebea4993454ee9d355e60ad9bea07
Yuchen Pei
MDEV-39535 Check for signs of EOF in ha_partition::handle_unordered_prev

The fields m_part_spec.start_part and m_part_spec.end_part defines the
range of partitions for index scans.

Of these two fields, m_part_spec.start_part is also commonly assigned
NO_CURRENT_PART_ID to indicate uninitialisation or failure mode.

MDEV-20195 shows problems when "unordered" scan fails to detect such a
condition for HANDLER ... NEXT statements.

MDEV-37330 allows "unordered" scan to handle index_prev. So we have a
similar problem for HANDLER ... PREV statements, and fix it by
checking for m_part_spec.start_part == NO_CURRENT_PART_ID in
ha_partition::handle_unordered_prev.

Furthermore, "ordered" index scans, i.e. index scans utilising a
priority queue checks m_top_entry against NO_CURRENT_PART_ID to detect
similar issues. Unlike m_part_spec.start_part, m_top_entry is set by
"ordered" scans only. This is why we have to do similar checks on
m_part_spec.start_part in "unordered" scans regardless of the
direction of the scan. Also because of this, in this patch we now set
m_part_spec.start_part only to NO_CURRENT_PART_ID in
ha_partition::handle_unordered_scan_next_partition for EOF.

Also renamed ha_partition::m_unordered_reverse_index to
ha_partition::m_unordered_reverse_scan because it is always false when
there is only one partition to scan.

Two of the testcases (the non-original ones) don't fail before the
patch, but they take the same path i.e. enter
ha_partition::handle_unordered_prev with m_part_spec.start_part ==
NO_CURRENT_PART_ID.
92c4de0c30a4...
92c4de0c30a4c853be1c0165b96d582132183063
Rucha Deodhar
MDEV-39449: Memory corruption (heap-buffer-overflow) in uint4korr and
Gcalc_function::count_internal, apparent partial stack looping in
Gcalc_function::count_internal and Assertion `(0)' failed in
Item_func_spatial_precise_rel::val_bool

Analysis:
ST_COVEREDBY() was linked with Item_func_spatial_precise_rel with
SP_COVEREDBY_FUNC, but the case was missing in val_bool() method.
This resulted in fall through switch leading to an assert/ASAN failure during

Fix:
Added the missing case and implemented it similar to WITHIN
(with MBR precheck + buffer). This fixes the crash and makes
ST_COVEREDBY() behave correctly.
902d05a22a75...
902d05a22a754ceb79669c6a9ecb37399282c17a
Rucha Deodhar
MDEV-39213: json range syntax crash

Analysis:
When json is being parsed, the step decreases without a out-of-bound check
resulting in failure.
Fix:
Before decreasing the step, check if it will result into out of bound.
8978a52132e4...
8978a52132e4c9bfc8886a9a0c8b3db41802b1ff
Oleksandr Byelkin
Merge branch '10.6' into bb-10.11-release
8721a00dd38d...
8721a00dd38dc0aa1514a3b5ca8c95c6e94af1c9
Yuchen Pei
MDEV-20195 Check for signs of EOF in partition "unordered scan"

When running HANDLER commands, there is no optimization to detect
const tables of empty rows and the handler states are not reset
between HANDLER NEXT statements, either in ha_partition::reset or in
ha_partition::partition_scan_set_up (for m_part_spec.start_part,
relevant to this task)

When doing a partition "unordered scan" (i.e. an ordered scan without
using priority queues), with the "first scan" in
ha_partition::handle_unordered_scan_next_partition, EOF causes
NO_CURRENT_PART_ID to be assigned to m_part_spec.start_part. In the
"subsequent scan" ha_partition::handle_unordered_next should check
this condition and return EOF directly, just like the "ordered scan"
ha_partition::handle_ordered_next.
86e849d9cc98...
86e849d9cc98bae288b0d0a0613b91cbb98bb4ce
Oleksandr Byelkin
fix
835df429bd43...
835df429bd4389968714f99dba735c26dc8deb4f
Oleksandr Byelkin
Merge branch '10.11' into bb-10.11-release
7696361ebea1...
7696361ebea1eae8ca8aeaee93482d722c92dfc7
Oleksandr Byelkin
Merge branch 'bb-11.8-release' into bb-12.3-release
7582e48ecdaf...
7582e48ecdaf1e096f1abdf24b24ce2064cf46da
Oleksandr Byelkin
Merge branch 'bb-10.11-release' into bb-11.4-release
6378d3c71647...
6378d3c71647967d8f5676b53dfb9194d8799df6
Oleksandr Byelkin
fix
5d8020d2914a...
5d8020d2914afe64d85f4b29634c0cda4f2c4cda
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
5ad5f3be5129...
5ad5f3be51291128d1d79bb36b768fb64043a03c
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
47f2278678e3...
47f2278678e32a392260cfe959122862222ae9e1
ParadoxV5
MDEV-39418: Revert most of MDEV-39240 for MDEV-32188

MDEV-39240 fixed how servers before 11.5/11.4-enterprise
accepted timestamps beyond Year 2038 from row-based replication,
which were invalid until 11.5/11.4-enterprise’s MDEV-32188.
MDEV-39240 does not apply after MDEV-32188 extended the valid range,
so those versions should exclude this fix,
as if MDEV-32188 already covers it.

This commit reverts commits 3234045953 and most of f9c34a1442, keeping
only the tweak to the MTR script `include/check_type` for consistency.
42d6f2156b0a...
42d6f2156b0afc88112bea547ee90b83fc2bfc06
Oleksandr Byelkin
fix
3ab37f31417d...
3ab37f31417d8980569b597f043e3b0233955dc7
Oleksandr Byelkin
Merge branch 'bb-11.8-release' into bb-12.3-release
3423513fffb2...
3423513fffb22d4102fb915cc48181f82d98b7f6
Rucha Deodhar
Fixes json test failures in func_json.test and mdev_32854.test in bb-12.3-release
32327e572bbd...
32327e572bbdfee6a2c2c60b4d37d3d1a0d61e3b
Sergei Golubchik
MDEV-39540 crash due to narrowing cast in update_ref_and_keys()
200eb5365a4d...
200eb5365a4ded078cfbdb51e755d74885cfbc41
Sergei Golubchik
MDEV-39516 s3 curl_easy_setopt requires long values otherwise compile failure

update submodule to compile on fc44
17511e537006...
17511e53700618f0daa2a3406343a57a93c50580
Rucha Deodhar
Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <[email protected]>
1053630fcad2...
1053630fcad2a3b4613312adaf96d1c3cc456786
Jan Lindström
MDEV-39413 wsrep unsafe handling of parameters

When server is started with unsafe parameter --exec could
return also error 134. Furthermore, --exed pkill could
return error 15. Added these error codes as accepted.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Fri 08 May 2026 03:41:45 (UTC)