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
fbdabe8aadf4...
fbdabe8aadf4365ac8dedb3d2776a14b1f42be15
Oleksandr Byelkin
Merge branch 'bb-10.11-release' into bb-11.4-release
ef24379a4535...
ef24379a4535a2364ad77c1def71fece9a376c9b
Sergei Golubchik
MDEV-39565 missing filename check in mariadb-backup --decompress

check for tablename-safe characters in backed up table files
ebe35a081278...
ebe35a081278c907cf169250aa2250675c5d8b22
forkfun
MDEV-24557 mariadb-dump: translate MySQL 8.x user/grant syntax for MariaDB import

  `mariadb-dump --system=users` can capture a MySQL 8.0+ source server
  and produce a dump that replays cleanly on MariaDB. In the dump file
  such statements appear twice, wrapped in `/*!80001 ... */` (MySQL-only)
  and `/*M!100005 ... */`(MariaDB-only)

  Tests:

  - main.mariadb-dump-mysql8-import
  - main.mariadb-dump-roles-regression
df3425bd004f...
df3425bd004f9830698578425763a6a497f7d0fc
Sutou Kouhei
MDEV-39545 Fix missing embedded TokenMecab finalization in Mroonga

We embed the `TokenMecab` plugin into Groonga and we embed Groonga
into Mroonga. If we embed a Groonga plugin, we need to
initialize/finalize it manually.

We have `grn_db_fin_mecab_tokenizer()` for finalizing the `TokenMecab`
plugin but it's called only when the current `grn_ctx` refers the
close target Groonga DB. Mroonga manages multiple Groonga DBs by
`mrn::DatabaseManager`. `mrn::DatabaseManager` uses one `grn_ctx` for
multiple Groonga DBs. So the current `grn_ctx` may have a different
Groonga DB when the current `grn_ctx` closes a Groonga DB. (It's not a
problem in Groonga API usage.)

We should always finalize the embedded `TokenMecab` plugin even if the
current `grn_ctx` refers a different Groonga DB because we always
initialize the embedded `TokenMecab` plugin.
d5873e7e6ec5...
d5873e7e6ec5818eceb9ed9bbb64d49915de703e
forkfun
MDEV-24557 mariadb-dump: translate MySQL 8.x user/grant syntax for MariaDB import

  `mariadb-dump --system=users` can capture a MySQL 8.0+ source server
  and produce a dump that replays cleanly on MariaDB. In the dump file
  such statements appear twice, wrapped in `/*!80001 ... */` (MySQL-only)
  and `/*M!100005 ... */`(MariaDB-only)

  Tests:

  - main.mariadb-dump-mysql8-import
  - main.mariadb-dump-roles-regression
d37e50c6d04c...
d37e50c6d04c7c27362f1668ae86fa592b94fb23
Oleksandr Byelkin
fix long name on view protocol
a9a93c4fc0ac...
a9a93c4fc0acb2a46c3ad1409e167e84bf58657a
Georgi (Joro) Kodinov
MDEV-39456: Describe the external contributions process in more details

Added a new .md document describing the community contribution process.
Added a reference to it from the CONTRIBUTING.md.
9ca5d19d8771...
9ca5d19d877100b215cb991a771258cd99bf1989
Georgi (Joro) Kodinov
MDEV-39456: Describe the external contributions process in more details

Added a new .md document describing the community contribution process.
Added a reference to it from the CONTRIBUTING.md.
94b37c66e93e...
94b37c66e93eb3733def553d79bbfd519e402f55
Alexey Botchkov
MDEV-39536 ASAN heap-buffer-overflow in process_str_arg upon ER_TRUNCATED_WRONG_VALUE "Incorrect XML value".

XML should be prepared before inserting it into the error message.
8eb9d167a4d5...
8eb9d167a4d50f2185c46c1d01c69cf44144e082
forkfun
MDEV-24557 mariadb-dump: translate MySQL 8.x user/grant syntax for MariaDB import

  `mariadb-dump --system=users` can capture a MySQL 8.0+ source server
  and produce a dump that replays cleanly on MariaDB. In the dump file
  such statements appear twice, wrapped in `/*!80001 ... */` (MySQL-only)
  and `/*M!100005 ... */`(MariaDB-only)

  Tests:

  - main.mariadb-dump-mysql8-import
  - main.mariadb-dump-roles-regression
8ca24141cfd9...
8ca24141cfd9a60300f2f98b3b38dbf26e549dc3
Razvan-Liviu Varzaru
Disable invalid-handle check under MSan

The invalid-handle check was disabled in a55878f4baa061fc9943228beecb91367d7d08fe for Valgrind
and MSan issues an warning originating from the Driver Manager, during the same call;

```
==26==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7a902a23c3a2 in __validate_stmt /msan-build/DriverManager/__handles.c:1375:20
    #1 0x7a902a1fc264 in __SQLFreeHandle /msan-build/DriverManager/SQLFreeHandle.c:398:19
    #2 0x559ce0edbbb9 in sqlchar /home/buildbot/odbc_build/source/test/unicode.c:270:12
    #3 0x559ce0ed4419 in run_tests_ex /home/buildbot/odbc_build/source/test/tap.h:1182:11
    #4 0x7a9029eccca7  (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: 58749c528985eab03e6700ebc1469fa50aa41219)
    #5 0x7a9029eccd64 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29d64) (BuildId: 58749c528985eab03e6700ebc1469fa50aa41219)
    #6 0x559ce0e2e670 in _start (/home/buildbot/odbc_build/build/bintar/test/odbc_unicode+0x34670) (BuildId: 92f183f3e775737cd445db531d16f5654952b845)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /msan-build/DriverManager/__handles.c:1375:20 in __validate_stmt
  ORIGIN: invalid (0). Might be a bug in MemorySanitizer origin tracking.
    This could still be a bug in your code, too!
Exiting
```
84dbc7956dfe...
84dbc7956dfe1bfca0fe08f7abf123fc893d71f1
Rex Johnston
MDEV-39492 Parallel Query: Study how to create worker threads

Introduces @@global.parallel_worker_threads (ulong, default 0,
range 0-16383, CONNECTION_ADMIN_ACL).  When non-zero and a top-level
SELECT is executed, JOIN::exec() spawns that many background threads
via create_background_thd() / mysql_thread_create() and waits for all
of them to finish before returning.

Vaguely assisted by Claude Sonnet 4.6
83186b3324d5...
83186b3324d51888b54007d21464937c0ed7bfb6
PranavKTiwari
added warning.
7ddd5eed1b07...
7ddd5eed1b0771d36bffbd5e71c33dcb620bda9d
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.
7b8dcc0cdb23...
7b8dcc0cdb23a2eac0974c4ff59edaa9cb753048
bsrikanth-mariadb
MDEV-39440: replay context throwed a warning for a query after altering an index

The problem is that handler->multi_range_read_info_const() call in
check_quick_select() returned rows equal to HA_POS_ERROR, both during
context capture and replay. However, we never stored the ranges info
into the context when rows=HA_POS_ERROR. However, during replay, we try
to infuse stats for the given range, and since no match was found in the
context, we produced a warning.

Solution is to store range_info for all the ranges even when they get
HA_POS_ERROR number of rows.
78e67bccf421...
78e67bccf421ba3c07e109715b205d3ab78e3b7e
PranavKTiwari
Updated in sequence.
70ec153f09df...
70ec153f09df4895cf1783fb6dddf344c81ef6ba
Lawrin Novitsky
Merge branch 'odbc-3.1'
6ee01e67d096...
6ee01e67d096654b61f063b3554aa8753ea4b11b
Rex Johnston
MDEV-39492 Parallel Query: Study how to create worker threads

Introduces parallel_worker_threads variable to control the number
of worker threads created by a parallel execution query.

2 new files, sql_parallel_workers.h sql_parallel_workers.cc which
contain structures for the creation, management and deletion of
parallel worker threads (pwt_ in the name).  Main management
class created in the stack in JOIN::exec, implemented for the
top level select.

Current parallel_worker_thread_func sleeps for a random time, generates
a warning, signals the main thread, sleeps a random time, signals the
main thread again, sets it's finished flag and cleans it's THD.

The main thread loops through worker threads, looking for finished
thread and cleans them up if they have finished.
It then waits for a signal, then processes it's message queue.

The thread management data is allocated on the stack in JOIN::exec.
Everything else is allocated using my_malloc() and my_free().
64bb79f110fa...
64bb79f110faa610ac014c884ccb246d6ad6ac45
Oleksandr Byelkin
Merge branch 'bb-11.8-merge' into bb-12.3-release
63711ec37ca9...
63711ec37ca9696800dfff1c44897d661b334d7a
Jan Lindström
MDEV-39561 : Galera test failure on mysql-wsrep-features#8

Test case changes only. Fix wait_conditions.
61e92e4da7d9...
61e92e4da7d9e1c03c2b4a2dbe8a2dcc871eab1b
Rex Johnston
MDEV-39492 Parallel Query: Study how to create worker threads

Introduces @@global.parallel_worker_threads (ulong, default 0,
range 0-16383, CONNECTION_ADMIN_ACL).  When non-zero and a top-level
SELECT is executed, JOIN::exec() spawns that many background threads
via create_background_thd() / mysql_thread_create() and waits for all
of them to finish before returning.

Vaguely assisted by Claude Sonnet 4.6
5d8020d2914a...
5d8020d2914afe64d85f4b29634c0cda4f2c4cda
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
58cc38e42d76...
58cc38e42d76e834186014ea2f4d54284b5aac8a
bsrikanth-mariadb
MDEV-39440: replay context throwed a warning for a query after altering an index

The problem is that handler->multi_range_read_info_const() call in
check_quick_select() returned rows equal to HA_POS_ERROR, both during
context capture and replay. However, we never stored the ranges info
into the context when rows=HA_POS_ERROR. However, during replay, we try
to infuse stats for the given range, and since no match was found in the
context, we produced a warning.

Solution is to store range_info for all the ranges even when they get
HA_POS_ERROR number of rows.
4ee78e6255a9...
4ee78e6255a900a45b0bfec6a86834f1b0f329d1
PranavKTiwari
Updated condition.
4c371e30f003...
4c371e30f003b601e7485533476208ae27d51937
Alexey Botchkov
MDEV-38809 RBR fails upon DML with XML type.

Add Field_xmltype::rpl_conv_type_from() function to control
replication data types.
46bc4cd079a0...
46bc4cd079a03040999b786ed7138ccfc2762b15
Oleksandr Byelkin
Revert "fix"

This reverts commit 42d6f2156b0afc88112bea547ee90b83fc2bfc06.
46271efd3a94...
46271efd3a94f0e5c2b287abb82d701844588c14
PranavKTiwari
Just a commit.
45c5c13b4d85...
45c5c13b4d85f1efa725e6556555aa5ee976f68a
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
- (SQL_W)VARCHAR and SQL_VARBIBARY is 65532

There were also some discrepences between values for ODBCv3 and ODBCv2
Enhanced existing test to check all these values and removed couple of
duplicating tests(one info and one in datetime)
3da3ec2ab192...
3da3ec2ab1923183a4c85b18c3a0145cae8dd3a6
Oleksandr Byelkin
Merge branch 'bb-11.4-release' into bb-11.8-release
2ee5595d091c...
2ee5595d091ce541594d2abc8b99f63b1ea48ea3
lawrinn
Revert "Disable invalid-handle check under MSan"

This reverts commit 8ca24141cfd9a60300f2f98b3b38dbf26e549dc3.
1ff3ce5578ee...
1ff3ce5578eece2f28f8cb0de44527d62db73090
Razvan-Liviu Varzaru
Disable invalid-handle check under MSan

The invalid-handle check was disabled in a55878f4baa061fc9943228beecb91367d7d08fe for Valgrind
and MSan issues an warning originating from the Driver Manager, during the same call;

```
==26==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7a902a23c3a2 in __validate_stmt /msan-build/DriverManager/__handles.c:1375:20
    #1 0x7a902a1fc264 in __SQLFreeHandle /msan-build/DriverManager/SQLFreeHandle.c:398:19
    #2 0x559ce0edbbb9 in sqlchar /home/buildbot/odbc_build/source/test/unicode.c:270:12
    #3 0x559ce0ed4419 in run_tests_ex /home/buildbot/odbc_build/source/test/tap.h:1182:11
    #4 0x7a9029eccca7  (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: 58749c528985eab03e6700ebc1469fa50aa41219)
    #5 0x7a9029eccd64 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29d64) (BuildId: 58749c528985eab03e6700ebc1469fa50aa41219)
    #6 0x559ce0e2e670 in _start (/home/buildbot/odbc_build/build/bintar/test/odbc_unicode+0x34670) (BuildId: 92f183f3e775737cd445db531d16f5654952b845)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /msan-build/DriverManager/__handles.c:1375:20 in __validate_stmt
  ORIGIN: invalid (0). Might be a bug in MemorySanitizer origin tracking.
    This could still be a bug in your code, too!
Exiting
```
1b896c481aae...
1b896c481aae2a72c81222e5e5c75ad5fe266163
Sergei Golubchik
MDEV-39564 One-byte OOB write in PROXY protocol v1 header parser
181f13ec49fd...
181f13ec49fdf14a873e9ebf7440133b3e0d70d9
Alexey Botchkov
MDEV-39536 ASAN heap-buffer-overflow in process_str_arg upon ER_TRUNCATED_WRONG_VALUE "Incorrect XML value".

XML should be prepared before inserting it into the error message.
156f47e2e841...
156f47e2e841f37431d872da346ccca99fc2ec6c
rusher
[misc] add maxscale testing to CI
14e545e5c642...
14e545e5c6425e36f02a8802d576e7547310f310
bsrikanth-mariadb
MDEV-39440: replay context throwed a warning for a query after altering an index

The problem is that handler->multi_range_read_info_const() call in
check_quick_select() returned rows equal to HA_POS_ERROR, both during
context capture and replay. However, we never stored the ranges info
into the context when rows=HA_POS_ERROR. However, during replay, we try
to infuse stats for the given range, and since no match was found in the
context, we produced a warning.

Solution is to store range_info for all the ranges even when they get
HA_POS_ERROR number of rows.
135f4ae54325...
135f4ae54325d3459c3c0182e17c48b195400ae8
PranavKTiwari
MDEV-38839: Fix assertion in close_thread_tables on CREATE TABLE...SELECT FOR UPDATE with MyISAM temp table in MIXED binlog mode

FOR UPDATE on a MyISAM table acquires TL_WRITE due to lack of
row-level locking. In decide_logging_format(), this caused
STMT_WRITES_TEMP_NON_TRANS_TABLE to be set for a temp table that
was only being read, not written to. This incorrectly set
MODIFIED_NON_TRANS_TABLE via mark_modified_non_trans_temp_table()
in MYSQL_BIN_LOG::write(), which blocked binlog_truncate_trx_cache()
in MIXED mode, leaving row events stranded in the cache and
triggering the assertion:

Fix: In decide_logging_format(), gate the write flag assignment on
tbl->updating, which is false for FOR UPDATE (read-only access with
write lock) and true for genuine writes (INSERT/UPDATE/DELETE).
04dea735b6b8...
04dea735b6b8596570eeb376d13c6236d3c74f1c
Oleksandr Byelkin
Merge branch 'bb-10.6-release' into bb-10.11-release
01e1b4f16928...
01e1b4f169282388543f2fb7992e8da944b3060a
bsrikanth-mariadb
MDEV-39505: Diff in rows column of explain plan for delete table stmt

Although, number of rows for a table got recorded in the context, for a
delete from table statement, but when replayed explain plan showed only
1 in the rows column.

There was no call being made to set_statistics_for_table() from
delete_from_single_table() when all rows are deleted from a table.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Tue 12 May 2026 01:22:41 (UTC)