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
f47c7b2a4117...
f47c7b2a4117a2f47d63188c29060147138a8769
Sergei Golubchik
w 6.0
df3d4315bc2e...
df3d4315bc2eace2df8f2f9112f27e1fdfef65c7
Marko Mäkelä
fixup! a1c90c41530fdc6558a5299bf9539769bf4e3617
d3028821709f...
d3028821709f9a4c221bf9235098b32a3fc358d8
Sergei Golubchik
w 4.1
b6fdb0a21962...
b6fdb0a21962f273cd8aa1ffc6bf33df32b040f4
Sergei Golubchik
w 6.4
b1fd0f4d4cfa...
b1fd0f4d4cfae108633dc3ffcb23be80a6185202
Sergei Golubchik
temporarily remove failing tests
a9e722c82a11...
a9e722c82a11cdd0dca09175604fc1d50a858e3e
Sergei Golubchik
w 4.3
a7ef17218757...
a7ef1721875796eca649b1e324c2c4b36447bc7d
Thirunarayanan Balathandayuthapani
MDEV-38942  i_s_dict_fill_sys_tables() aborts when reading INNODB_SYS_TABLES after innodb_force_recovery

Problem:
========
  A query on INFORMATION_SCHEMA.INNODB_SYS_TABLES crashes when
SYS_TABLES contains a record that was inserted by a transaction
which has not been committed. This can happen after a
crash while a CREATE TABLE was in progress, if the server is
restarted with innodb_force_recovery=4 or greater,
because trx_rollback_recovered() is then skipped and the
recovered transaction remains ACTIVE.

dict_sys_tables_rec_read() returns READ_NOT_FOUND for such a
record, and dict_load_table_low() returns that as success with no
error message and setting *table to nullptr.
i_s_sys_tables_fill_table() checks only the error
message and passes the nullptr table to i_s_dict_fill_sys_tables(),
which dereferences it.

Solution:
========
i_s_sys_tables_fill_table(): Skip the SYS_TABLES record when
dict_load_table_low() reports success but returns no table, because
such a record is not visible.
a5d56f628093...
a5d56f628093f69e64e4c2104a96c44798633faf
Sergei Golubchik
ft_json ft parser
a332344f4e7a...
a332344f4e7a2d9b5278f1f95c0ba14de2f4782d
Alexander Barkov
MDEV-39518 Allow prepared statements in stored functions in assignment right hand

Allowing prepared statements in stored functions when
a stored function is used in an assignment right hand.

Both DEFAULT clause of a variable initialization and
the right side of the SET statement are supported:

  CREATE PROCEDURE p1()
  BEGIN
    -- case 1: DEFAULT clause
    DECLARE spvar1 INT DEFAULT f1_with_ps(); -- OK

    -- case 2: SP variable assignment statement
    DECLARE spvar2 INT;
    SET spvar2= f1_with_ps(); -- OK
  END;

- Only assignments to SP variables works for now:
  * SET spvar= func_with_ps(); -- OK
  * SET @uvar= func_with_ps(); -- Error

- Only bare function calls are supported for now. Using a function in
  an expression does not make it PS-safe yet:
    SET v= f1()+0;

- The parser now does not reject PS statements in stored functions.
  PS applicability in stored functions is now detected at run time.
  Note, PS statements in triggers are still prohibited by the parser.

- Functions with PS do not acquire MDL locks on tables, and no MDL is
  taken on the routines themselves either. They work like procedures in
  terms of table opening and routine locking: a concurrent DROP FUNCTION
  can complete while such a function is executing.

- Functions with PS are not replicated as a single `SELECT f1()` call.
  They are replicated per-statement, like procedures.

Helper changes:
- Changing the return result for LEX::sp_variable_declarations_init()
  from void to bool to catch errors in the caller properly.

Misc:
- This patch incorporates fixes for the following bugs found during debugging:
  MDEV-40224,MDEV-40225,MDEV-40226,MDEV-40227,MDEV-40240,
  MDEV-40285,MDEV-40288,MDEV-40315,MDEV-40318,MDEV-40890,MDEV-40900,
  MDEV-40901,MDEV-40913,MDEV-40914,MDEV-41013,MDEV-41015,MDEV-41019

Assisted-by: Claude - reviews and minor clean-ups
a1c90c41530f...
a1c90c41530fdc6558a5299bf9539769bf4e3617
Marko Mäkelä
WIP: log tracking BACKUP SERVER TO ... CONCURRENT (for HAVE_INNODB_PMEM)

backup_sink::id: The thread identifier (0 to CONCURRENT-1)

innodb_backup_checkpoint_pmem(): Copy the old log file.

InnoDB_backup::log_track(), InnoDB_backup::log_track_pmem():
Keep copying the log until we run out of InnoDB data files to copy.

InnoDB_backup::checkpoint_complete_pmem(): Copy the remaining
part of an old log file right before it is being released.

InnoDB_backup::commit(): In log tracking backup, copy the rest of
the HAVE_INNODB_PMEM log.

FIXME: Implement the non-PMEM code path with minimal blocking.
a189db81465e...
a189db81465e924e8540e3996cd476ad7e9544a6
Sergei Golubchik
w 4.2
9b93dc72103c...
9b93dc72103cb73cabfefa43c9bbe2f32ef859fd
Khaled Riyad
MDEV-37335: crash on re-parsing an sp_instr_set that does not own its LEX

A DECLARE of several variables with a common DEFAULT expression creates one
sp_instr_set per variable, all sharing a single LEX that only the last of
them owns. On re-parsing after a metadata change, a non-owning instruction
still has its LEX, and both parse_expr() and validate_lex_and_exec_core()
took a non-null LEX to mean a cursor LEX. The cursor-only code then
dereferenced the nullptr returned by get_lex_for_cursor() and the re-parsed
LEX was never adopted.

Branch on whether the LEX is a cursor LEX instead of whether it is non-null.
993383a8507b...
993383a8507b438fea83713aad78fd91e49f69ed
Sergei Golubchik
w 4.6
902c5324ebd7...
902c5324ebd71ba0d961538f9b50959af149c71c
Sergei Golubchik
w 5.2
8d91926618c0...
8d91926618c028a1f80567438406bf0333bd062d
Sergei Golubchik
w 5.3
88b0ce43b79e...
88b0ce43b79e3b5825e7a9d5e6f44bbe8b6a9360
Sergei Golubchik
w 6.1
828f77b8edb4...
828f77b8edb463c9434aa92eabd17f0758819666
Sergei Golubchik
w
771860bc4f6d...
771860bc4f6d983e2ba8f30aa4e554eabdf58a07
Sergei Golubchik
w3

* FULLTEXT_USING_ENGINE old mode
* FULLTEXT (...) USING TABLE to select new implementation
7474f7e3fa74...
7474f7e3fa7425f1e81261eaa9e00ffc4d486a6d
Sergei Golubchik
w 5.1
72f729d06606...
72f729d06606b5f9a21d5db43465557bac3ba6ab
Sergei Golubchik
w 6.3
71e885c7de58...
71e885c7de58d5f521cf4322e365e6f9d8b81be3
Sergei Golubchik
w 6.6 EXPLAIN
6df6a2d2eb60...
6df6a2d2eb60882ea22d30106e2ee77442f1cda1
Sergei Golubchik
w 6.5 copy more tests over
6d391a7dddb2...
6d391a7dddb2fee58498430d227d7f3d107a68dc
Rex Johnston
MDEV-40005 Parallel Query: a worker scanned the wrong index

The SQL layer opens a private TABLE, and so a private handler, per
worker. parallel_init_coordinator() records the scan parameters on the
master's handler, which a worker's handler has never seen: its
m_pscan_keynr is still MAX_KEY, the clustered index, while the chunk
boundaries it gets handed were computed on the secondary index the plan
chose.

Pass the coordinator's handler to parallel_init_worker() and take the
parameters from it in pscan_adopt_scan_params(), before anything reads
m_pscan_keynr. The ranges are borrowed rather than copied: they live in
the master's m_pscan_range_heap, freed by parallel_end_coordinator()
only once every worker has been joined, so parallel_end_worker() drops
the pointers again on a handler that does not own the heap.
5f2cc3e39348...
5f2cc3e39348d0152f9d4714406023442669642d
Vladislav Vaintroub
MDEV-41008: Fix X509 issuer/subject comparison for OpenSSL 3

OpenSSL 3 escapes '/' and '+' in X509_NAME_oneline() output;
OpenSSL 1.1 and WolfSSL don't. A REQUIRE ISSUER/SUBJECT grant from
one library can stop matching after switching to another.

Default comparison stays strcmp(). old_mode=X509_LENIENT_COMPARE
opts into ignoring the escaping backslash, at the cost of reopening
the single-RDN-vs-multi-RDN ambiguity a crafted certificate could
exploit to impersonate another identity.

Also fixes sysvars_server_embedded/notembedded for the new old_mode
value, and guards my_x509_oneline_cmp() against X509_NAME_oneline()
returning NULL.
5e13a1835c5f...
5e13a1835c5f6edda88faf81535cca6e50342bda
Sergei Golubchik
w 4.8
53322cdd5ba8...
53322cdd5ba8d268586cbdbe66529c98eb6113cb
Khaled Riyad
MDEV-37335: crash on re-parsing an sp_instr_set that does not own its LEX

A DECLARE of several variables with a common DEFAULT expression creates one
sp_instr_set per variable, all sharing a single LEX that only the last of
them owns. On re-parsing after a metadata change, a non-owning instruction
still has its LEX, and both parse_expr() and validate_lex_and_exec_core()
took a non-null LEX to mean a cursor LEX. The cursor-only code then
dereferenced the nullptr returned by get_lex_for_cursor() and the re-parsed
LEX was never adopted.

Branch on whether the LEX is a cursor LEX instead of whether it is non-null.
4f166fc2a7d9...
4f166fc2a7d9a1d2269bda51c14441799e88fb8c
Vladislav Vaintroub
MDEV-41008: Fix X509 issuer/subject comparison for OpenSSL 3

OpenSSL 3 escapes '/' and '+' in X509_NAME_oneline() output;
OpenSSL 1.1 and WolfSSL don't. A REQUIRE ISSUER/SUBJECT grant from
one library can stop matching after switching to another.

Default comparison stays strcmp(). old_mode=X509_LENIENT_COMPARE
opts into ignoring the escaping backslash, at the cost of reopening
the single-RDN-vs-multi-RDN ambiguity a crafted certificate could
exploit to impersonate another identity.
4c6febe4084b...
4c6febe4084b1caf219e9301602988fe3fa0045b
Sergei Golubchik
w 4.7
42038e1145dd...
42038e1145dd43b3910055c364fb720a8a152d61
Thirunarayanan Balathandayuthapani
MDEV-26057 Assertion `!vcol->v_indexes.empty() in trx_undo_log_v_idx

Problem:
========
-  Rollback of an INPLACE ALTER TABLE is executed while holding only a
shared metadata lock on the table, so DML can run concurrently.
rollback_inplace_alter_table() resets dict_col_t::ord_part in a
critical section of its own, after row_merge_drop_indexes() already
removed the aborted indexes from the dictionary cache and emptied
dict_v_col_t::v_indexes. During this time, DML statement can see a
virtual column with ord_part set and an empty v_indexes, which
makes assert failure in trx_undo_report_insert_virtual().

Solution:
========
row_merge_reset_ord_part(): Added a function to reset
dict_col_t::ord_part for the columns that are no longer a field of
any index remaining in the dictionary cache.
For virtual columns the decision is based on dict_v_col_t::v_indexes
being empty, and no element is ever removed from that list.

row_merge_drop_indexes(): Added a call to row_merge_reset_ord_part()
in the branch that removes the indexes from the cache, in the same
dict_sys.latch critical section. That branch is taken only when
MDL_EXCLUSIVE is held or when this is the only handle to the table,
so no concurrent DML can observe the intermediate state.
In the lazy drop branch the indexes and their v_indexes entries
stay in the cache and nothing is reset; that is done later,
when the indexes are dropped while holding MDL_EXCLUSIVE.

check_col_exists_in_indexes(): Removed the only_committed parameter,
which no longer has any caller.

row_quiesce_col_ord_part(): Added a function to get
dict_col_t::ord_part and dict_col_t::max_prefix of a column
from the committed indexes that are
present in the dictionary cache.

row_quiesce_write_table(): Write the row_quiesce_col_ord_part() return
values to the .cfg file instead of the cached dict_col_t fields,
because a rolled back ADD INDEX leaves ord_part set until the
aborted index is removed by a later DDL, and
max_prefix is never reset when an index is dropped, which makes
IMPORT TABLESPACE reject the tablespace with a bogus schema mismatch.
3ff52728cc8d...
3ff52728cc8d868cb6bd60f9280715a710f95612
Sergei Petrunia
A plain KEY is the only index type allowed over an ARRAY

    create table t1 (j json, unique key idx ((CAST(j->'$.a' AS CHAR(6) ARRAY))));
    create table t1 (j json, primary key ((CAST(j->'$.a' AS CHAR(6) ARRAY))));
    create table t1 (j json, fulltext key idx ((CAST(j->'$.a' AS CHAR(6) ARRAY))));

were all accepted without a word, and all produced the same thing: a plain
index. The key type the user wrote was simply overwritten with
Key::FULLTEXT, so the table ended up with no unique constraint, or no
primary key, or with a FULLTEXT index that MATCH() finds nothing in - the
index holds encoded element keys, not the text.

What the server builds for an ARRAY is a fulltext index over those encoded
elements, and it can only mean what a plain KEY means. Say so: reject any
other type, in the grammar, before that overwrite loses what was asked for.
CONSTRAINT ... UNIQUE and the ALTER TABLE forms go the same way. SPATIAL
and VECTOR are already syntax errors for an ARRAY key part; they are in the
switch anyway so it stays exhaustive.

FOREIGN KEY is unaffected: it builds its key with Key::MULTIPLE and cannot
be told apart here. It is rejected, further down, by the engine - "Foreign
key constraint is incorrectly formed".

The count of key parts is now also checked in the grammar, and not only in
init_key_part_spec(). Otherwise the first ARRAY part of a two-part key sets
the type to FULLTEXT, and the second part reports "Incorrect usage of
FULLTEXT and ARRAY" for a key nobody declared FULLTEXT. As a side effect
KEY idx (c,(CAST(... ARRAY))) now gives the same "max 1 parts" error as the
other orders, instead of ER_BAD_FT_COLUMN for `c'.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
3bb69dca95c3...
3bb69dca95c313191858c177c83bf076960ecc0c
Sergei Golubchik
w 4

* in addition to hlindexton add hlindex and hlinex_share (sic!)
39fe827c4ef6...
39fe827c4ef6fc8c9fc7a440f77e1413877c4b50
Sergei Golubchik
account for ignored hlindexes (test?)
32833cdc4dd8...
32833cdc4dd860b1f631cf98aae9421e837e2756
Sergei Petrunia
Only allow one key part in an index over an ARRAY

    create table t1 (j json, key idx ((CAST(j->'$.a' AS CHAR(6) ARRAY)),
                                      (CAST(j->'$.b' AS CHAR(6) ARRAY))));

was accepted without a word. Each ARRAY key part gets an internal column of
its own, and they all became key parts of one fulltext key: the tokens of
both arrays end up mixed in a single index, and the optimizer would then
search that index for the keys of one array and get the rows of the other as
well. There is also no way to show such a key, or to read one back.

init_key_part_spec() now rejects a key that has an ARRAY key part and more
than one key part, on both the CREATE TABLE and the ALTER TABLE path.

The other order, KEY idx (c,(CAST(... ARRAY))), was already rejected: the
ARRAY part makes the key FULLTEXT, and `c' cannot be part of one.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2c4f73c84104...
2c4f73c84104a971e0c792e0449c5ae69d0669b6
Sergei Golubchik
w 4.5
2a9e1e082b5e...
2a9e1e082b5e939fabbe22c0d226e5a089bc0350
Alexander Barkov
MDEV-39518 Allow prepared statements in stored functions in assignment right hand

Allowing prepared statements in stored functions when
a stored function is used in an assignment right hand.

Both DEFAULT clause of a variable initialization and
the right side of the SET statement are supported:

  CREATE PROCEDURE p1()
  BEGIN
    -- case 1: DEFAULT clause
    DECLARE spvar1 INT DEFAULT f1_with_ps(); -- OK

    -- case 2: SP variable assignment statement
    DECLARE spvar2 INT;
    SET spvar2= f1_with_ps(); -- OK
  END;

- Only assignments to SP variables works for now:
  * SET spvar= func_with_ps(); -- OK
  * SET @uvar= func_with_ps(); -- Error

- Only bare function calls are supported for now. Using a function in
  an expression does not make it PS-safe yet:
    SET v= f1()+0;

- The parser now does not reject PS statements in stored functions.
  PS applicability in stored functions is now detected at run time.
  Note, PS statements in triggers are still prohibited by the parser.

- Functions with PS do not acquire MDL locks on tables, and no MDL is
  taken on the routines themselves either. They work like procedures in
  terms of table opening and routine locking: a concurrent DROP FUNCTION
  can complete while such a function is executing.

- Functions with PS are not replicated as a single `SELECT f1()` call.
  They are replicated per-statement, like procedures.

Helper changes:
- Changing the return result for LEX::sp_variable_declarations_init()
  from void to bool to catch errors in the caller properly.

Misc:
- This patch incorporates fixes for the following bugs found during debugging:
  MDEV-40224,MDEV-40225,MDEV-40226,MDEV-40227,MDEV-40240,
  MDEV-40285,MDEV-40288,MDEV-40315,MDEV-40318,MDEV-40890,MDEV-40900,
  MDEV-40901,MDEV-40913,MDEV-40914,MDEV-41013,MDEV-41015,MDEV-41019

Assisted-by: Claude - reviews and minor clean-ups
289e9c043814...
289e9c043814ddb7b6c50cd44dc1650be7ed57cf
Alexander Barkov
MDEV-39518 Allow prepared statements in stored functions in assignment right hand

Allowing prepared statements in stored functions when
a stored function is used in an assignment right hand.

Both DEFAULT clause of a variable initialization and
the right side of the SET statement are supported:

  CREATE PROCEDURE p1()
  BEGIN
    -- case 1: DEFAULT clause
    DECLARE spvar1 INT DEFAULT f1_with_ps(); -- OK

    -- case 2: SP variable assignment statement
    DECLARE spvar2 INT;
    SET spvar2= f1_with_ps(); -- OK
  END;

- Only assignments to SP variables works for now:
  * SET spvar= func_with_ps(); -- OK
  * SET @uvar= func_with_ps(); -- Error

- Only bare function calls are supported for now. Using a function in
  an expression does not make it PS-safe yet:
    SET v= f1()+0;

- The parser now does not reject PS statements in stored functions.
  PS applicability in stored functions is now detected at run time.
  Note, PS statements in triggers are still prohibited by the parser.

- Functions with PS do not acquire MDL locks on tables, and no MDL is
  taken on the routines themselves either. They work like procedures in
  terms of table opening and routine locking: a concurrent DROP FUNCTION
  can complete while such a function is executing.

- Functions with PS are not replicated as a single `SELECT f1()` call.
  They are replicated per-statement, like procedures.

Helper changes:
- Changing the return result for LEX::sp_variable_declarations_init()
  from void to bool to catch errors in the caller properly.

Misc:
- This patch incorporates fixes for the following bugs found during debugging:
  MDEV-40224,MDEV-40225,MDEV-40226,MDEV-40227,MDEV-40240,
  MDEV-40285,MDEV-40288,MDEV-40315,MDEV-40318,MDEV-40890,MDEV-40900,
  MDEV-40901,MDEV-40913,MDEV-40914,MDEV-41013,MDEV-41015,MDEV-41019

Assisted-by: Claude - reviews and minor clean-ups
2496f0615611...
2496f06156119254c0d846af72c543f8cce2f1fc
Sergei Petrunia
Show multi-valued indexes in SHOW CREATE TABLE

    create table t1 (c int, j json,
                    key idx ((CAST(j->'$.tags' AS CHAR(6) ARRAY))));

printed the two columns and no index at all. Nobody had decided to hide it:
it inherited invisibility from the internal column that backs it. The
grammar makes DB_MVI_<n> INVISIBLE_FULL, init_from_binary_frm_image() turns
a hidden key part into a hidden key, and store_create_info() skips keys with
HA_INVISIBLE_KEY. Long unique hash keys - the other kind of key built over a
column the user cannot name - are already exempted from that; exempt the
multi-valued index the same way, and print it as

  KEY `idx` ((cast(json_extract(`j`,'$.tags') as char(6) array)))

which is the expression it was declared with and all it takes to re-create
it. The internal column stays out of the output: it cannot be printed as a
column, since there is no syntax that would recreate the pairing.

Item_func_mvi_encode::print() cannot produce that form. Its output is what
pack_expression() puts in the FRM, and that is read back as a call of
mvi_encode(), the only form the parser accepts outside an index definition.
So the CAST spelling gets a printer of its own, sharing the type printing.

SHOW INDEX and I_S.STATISTICS list the key now too - the key part is let
through the invisibility filter - so they no longer need
debug_dbug=test_invisible_index, and the tests stop setting it (it also
injected a stray invisible1 column and key into their output).

The same HA_INVISIBLE_KEY drove mysql_prepare_alter_table(), which drops
such keys from the list of keys carried into the rebuilt table - and
INVISIBLE_FULL columns from the list of columns. So

    ALTER TABLE t1 ADD COLUMN x INT;

silently dropped the index. The key survives now, and its column is carried
over with it, for exactly as long as the key lives: DROP KEY takes the
column with it, so the name is free again afterwards.

While at it, make_internal_field_name() looped forever when create_list is
empty: dup_found started at true and the loop that clears it does not run.
The MVI path is the only caller that can hit that, and it does - with
ALTER TABLE ... ADD KEY ((CAST(... ARRAY))), which used to hang the server
and now works.

A fulltext key over several arrays,

    KEY idx ((CAST(j->'$.a' AS CHAR(6) ARRAY)),
            (CAST(j->'$.b' AS CHAR(6) ARRAY)))

has no single expression to print and no syntax of its own to be read back,
so it stays hidden, exactly as before. The optimizer still uses its parts.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
139c400bd067...
139c400bd0672802e4c76740d4e1d4a7a85a5965
Sergei Golubchik
w 4.4
0aa4865c7269...
0aa4865c7269ed08100be23e46c3911e97ce272c
Sergei Golubchik
w 5.4
08aaa2cf59dc...
08aaa2cf59dca301fec85cbfcffe796752ceb97b
Sergei Golubchik
a.test: fix encoding
BuildBot (0.8.9) working for the MariaDB project.
Page built: Mon 07 Sep 2026 17:57:28 (UTC)