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
Sergei Golubchik
cleanup: rename an argument
Oleg Smirnov
MDEV-39349 NO_INDEX hint using QB_NAME doesn't work inside VIEWs
Dave Gosselin
MDEV-39441: Add dbug_print() helpers for join-related types

Introduces new dbug_print() functions for the following types:
  dbug_print(NESTED_JOIN)
  dbug_print(JOIN)
  dbug_print(TABLE_LIST)
  dbug_print(JOIN_TAB)
  dbug_print(List<Item>)

Typically pointers to instances of the given types are passed.
The dbug_print(List<Item>) is intended to show result row before
sending to client (e.g., invoke in debugger while tracing end_send)
but may work in other contexts.

These functions produce nicely formatted output, please use them
in conjunction with the formatted printfs available in GDB or LLDB:
  (gdb) printf "%s", dbug_print(join_tab)
  (lldb) p printf("%s", dbug_print(table))

Example output from dbug_print(JOIN) in LLDB.  The last line with
value 1302 is the number of characters produced by the printf
command.

(lldb) p printf("%s",dbug_print(join))
JOIN [0x15801bfe8]  table_count=3  const_tables=0
join_list 0x158018340 [1 element(s)]:
--- #0 ---
  [0x15801af10] "(nest_last_join)"  join=INNER (outer_join=0)  nested_join=0x15801b618 (elements=2)
    NESTED_JOIN [0x15801b618]
      used_tables:    0x0
      not_null_tables: 0x0
      n_tables:        0
      counter:        0
      nest_type:      1 (JOIN_OP_NEST)
      nj_map:          0x0
      join_list:
        join_list 0x15801b618 [2 element(s)]:
        --- #0 ---
          [0x15801a308] "t3"  join=LEFT (outer_join=1)  map=0x4
            ON: `test`.`t2`.`a` = `test`.`t3`.`a`
        --- #1 ---
          [0x158019b30] "(nest_last_join)"  join=INNER (outer_join=0)  nested_join=0x15801a238 (elements=2)
            NESTED_JOIN [0x15801a238]
              used_tables:    0x0
              not_null_tables: 0x0
              n_tables:        0
              counter:        0
              nest_type:      0
              nj_map:          0x0
              join_list:
                join_list 0x15801a238 [2 element(s)]:
                --- #0 ---
                  [0x1580187c0] "t1"  join=RIGHT (outer_join=2)  map=0x1
                    ON: `test`.`t1`.`a` = `test`.`t2`.`a`
                --- #1 ---
                  [0x158018f08] "t2"  join=INNER (outer_join=0)  map=0x2
(int) 1302
Sergei Petrunia
More --disable_replay commands (3).
Daniel Black
MDEV-38771 RPM conflicts between MariaDB-common and mysql-common

mysql-common and MariaDB-common don't install the same files.
mysql-common (in MySQL 8.0) installs character set files
(/usr/share/mysql/charsets/*) and /usr/lib64/mysql (directory only).

MariaDB common installs character set files in /usr/share/mariadb
and the same /usr/lib64/mysql directory along with client plugins
in /usr/lib64/mysql/plugin. The RPM rules of conflict
only will cause troubles on directories if they are installed with
different metatadata (selinux, ownership, permissions) which isn't
the case.

As the character sets are at a different location MariaDB-common
isn't obsoleting mysql-common in a way that provides compatibilty
with mysql-common, for mysql-libs or otherwise, so its just creating
an install conflict.

Users installing perl-DBD-MySQL notice this because its mysql-libs
dependency pulls mysql-common, which conflicts with MariaDB-common.

We correct by removing the conflict and the provides of MariaDB-common
with resepect to mysql-common.
Rophy Tsai
MDEV-38550: add LENENC support for COM_CHANGE_USER

Add support for CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA in COM_CHANGE_USER
packet parsing, allowing passwords >= 251 bytes.

Changes:
- Server: parse_com_change_user_packet() now handles LENENC-encoded
  password length when CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA is set
- Server: fix db pointer calculation for old protocol without
  CLIENT_SECURE_CONNECTION (need +1 to skip null terminator)
- Add regression test for COM_CHANGE_USER with long passwords

Note: This fix requires a corresponding client-side fix in libmariadb's
send_change_user_packet() to send LENENC-encoded passwords.
ParadoxV5
MDEV-38600: Annotate the binlogging of recreating MEMORY tables

The data in MEMORY tables is temporary and is lost when the server
restarts. Thus, it is well-intentioned to record TRUNCATE statements
to the binary log when these tables are rediscovered empty. However,
as entries with no explicit user query associated (especially the lack
of SHUTDOWN on crashes), those unaware of this mechanism can find them
unexpected, not to mention their significance downstream in replication.

This commit adds a comment to these automatically generated
TRUNCATE entries to briefly self-describe their source and purpose.
As a part of the generated query, this comment is visible together
with the TRUNCATE itself in SHOW BINLOG EVENTS and `mariadb-binlog`,
while maintaining seamlessness in replication.

There are no other changes in behaviour or storage engine API.

Reviewed-by: Andrei Elkin <[email protected]>
ParadoxV5
MDEV-38600: Warn when recreating MEMORY tables on read-only slaves

The data in MEMORY tables is temporary and is lost when the server
restarts. Thus, when these tables are rediscovered empty,
it’s well-intentioned to record TRUNCATE statements to
the binary log, complete with an increment to the `@@gtid_binlog_pos`.
However, those unaware of this mechanism may not expect this increment
and its sign of replication divergence, namely in `@@gtid_strict_mode`.

This commit adds a binary log warning
when such a table is found `implicit_emptied`.

Since general uses of memory tables may already expect this effect,
to avoid unnecessary verbosity, this warning only emits from
`@@read_only` servers with CHANGE MASTER configured. `@@read_only`
indicates that the server should not receive changes; for a slave,
it means it only expects replication to binlog changes with GTID.

Reviewed-by: Brandon Nesterenko <[email protected]>
Sergei Golubchik
MDEV-38550 post-merge fixes

* update to the fixed libmariadb
* update test to match, remove useless INSTALL PLUGIN
* address remaining review comments
Oleksandr Byelkin
zlib 1.3.2
ParadoxV5
MDEV-38600: Warn when recreating MEMORY tables on read-only slaves

The data in MEMORY tables is temporary and is lost when the server
restarts. Thus, when these tables are rediscovered empty,
it’s well-intentioned to record TRUNCATE statements to
the binary log, complete with an increment to the `@@gtid_binlog_pos`.
However, those unaware of this mechanism may not expect this increment
and its sign of replication divergence, namely in `@@gtid_strict_mode`.

This commit adds a binary log warning
when such a table is found `implicit_emptied`.

Since general uses of memory tables may already expect this effect,
to avoid unnecessary verbosity, this warning only emits from
`@@read_only` servers with CHANGE MASTER configured. `@@read_only`
indicates that the server should not receive changes; for a slave,
it means it only expects replication to binlog changes with GTID.

Reviewed-by: Brandon Nesterenko <[email protected]>
Yuchen Pei
Merge branch '10.11' into 11.4
Daniel Black
MDEV-39207: Fix plugin name passed to find_bookmark in test_plugin_options (test postfix)

Under cursor/ps-protocol(Debug buidl) the UNINSTALL SONAME
in the cleanup could generate WARN_PLUGIN_BUSY during shutdown.

Disable the cursor and ps-protocol around the
disconnect and uninstall soname to resolve the test failure.

Concept/Review/Testing with: Yuchen Pei
Thirunarayanan Balathandayuthapani
MDEV-39081 InnoDB: tried to purge non-delete-marked record, assertion fails in row_purge_del_mark_error

Reason:
=======
Following the changes in MDEV-38734, the server no longer marks
all indexed virtual columns during an UPDATE operation.
Consequently, ha_innobase::update() populates the upd_t vector
with old_vrow but omits the actual data for these virtual columns.

Despite this omission, trx_undo_page_report_modify() continues to
write metadata for indexed virtual columns into the undo log. Because
the actual values are missing from the update vector, the undo log
entry is recorded without the historical data for these columns.

When the purge thread processes the undo log to reconstruct a
previous record state for MVCC, it identifies an indexed virtual
column but finds no associated data.

The purge thread incorrectly interprets this missing data as a NULL
value, rather than a "missing/unrecorded" value. The historical
record is reconstructed with an incorrect NULL for the virtual column.
This causes the purge thread to incorrectly identify and purge
records that are not actually delete-marked, leading to abort
of server.

Solution:
=========
ha_innobase::column_bitmaps_signal(): Revert the column-marking
logic to the state prior to commit a4e4a56720c, ensuring all
indexed virtual columns are unconditionally marked during an UPDATE.

The previous "optimization" attempted to manually detect indexed
column changes before marking virtual columns. The manual check
for indexed column modifications is redundant. InnoDB already
provides the UPD_NODE_NO_ORD_CHANGE flag within row_upd_step().
This flag is being used in trx_undo_page_report_modify() and
trx_undo_read_undo_rec() should log or read virtual column values.

Refactored column_bitmaps_signal() to accept a mark_for_update
parameter that controls when indexed virtual columns are marked.
TABLE::mark_columns_needed_for_update() is the only place that needs
mark_for_update=true because only UPDATE operations need to mark
indexed virtual columns for InnoDB's undo logging mechanism.

INSERT operation is already handled by
TABLE::mark_virtual_columns_for_write(insert_fl=true).
Even the commit a4e4a56720c974b547d4e469a8c54510318bc2c9 changes are
going to affect TABLE::mark_virtual_column_for_write(false) and
It is called during UPDATE operation, and that's when
column_bitmaps_signal() needs to mark  indexed virtual columns.

Online DDL has separate code path which is handled by
row_log_mark_virtual_cols() for all DML operations
ParadoxV5
Merge branch '10.11' into MDEV-38600
ParadoxV5
MDEV-38600: Warn when recreating MEMORY tables on read-only slaves

The data in MEMORY tables is temporary and is lost when the server
restarts. Thus, when these tables are rediscovered empty,
it’s well-intentioned to record TRUNCATE statements to
the binary log, complete with an increment to the `@@gtid_binlog_pos`.
However, those unaware of this mechanism may not expect this increment
and its sign of replication divergence, namely in `@@gtid_strict_mode`.

This commit adds a binary log warning
when such a table is found `implicit_emptied`.

Since general uses of memory tables may already expect this effect,
to avoid unnecessary verbosity, this warning only emits from
`@@read_only` servers with CHANGE MASTER configured. `@@read_only`
indicates that the server should not receive changes; for a slave,
it means it only expects replication to binlog changes with GTID.

Reviewed-by: Brandon Nesterenko <[email protected]>
Sergei Golubchik
MDEV-38199 Optimizer Error with = SOME on UNIQUE Column Using Decimal/Integer Types

return 1 (non-fatal error) when a decimal or float number
was modified when stored in Field_long (= fractional part was lost).

This tells the optimizer that a number with a non-zero fractional
part cannot be found in an index over an integer field.
Sergei Golubchik
zlib 1.3.2
Rucha Deodhar
MDEV-39212: JSON_MERGE_PATCH depth crash

Analysis:
The crash happens because we run out of stack space

Fix:
Add a stack overflow check.
Sergei Golubchik
MDEV-39318 MTR: fix test failures when running with --ssl

make sure P_S.{global|session}_status and I_S.feedback plugin table
have a column of the same width as I_S.global_status.

Otherwise long status strings (e.g. Ssl_cipher_list) won't fit
and trigger a data truncation warning (an error in the strict mode)
ParadoxV5
Fix `$target_temp_format` in `rpl.rpl_typeconv`

The MTR snippet `suite/rpl/include/check_type.inc`
was setting `@@GLOBAL.mysql56_temporal_format` with the wrong variable.
Sergei Golubchik
cleanup: remove explicit rounding before decimal2longlong

embed rounding into decimal2longlong instead.
this avoid carry propagation loop on rounding.
and allows decimal2longlong detect truncation correctly
Yuchen Pei
MDEV-39217 Fix the hash key calculation in session sysvar tracker

MDEV-31751 changed the key from the sys_var pointer to its offset.
This was useful for non-plugin variable aliases, but not so much for
plugin variables which all have offset 0.
Brandon Nesterenko
MDEV-38830: SIGSEGV and UBSAN null-pointer-use in TABLE::evaluate_update_default_function on UPDATE

MDEV-38716 (fa36b269f13) fixes were incomplete. It still allowed a
table's default_fields to be left un-restored after an ALTER table
finished its copy_data_between_fields().

This patch actually matches the original conception of MDEV-38716. It
was later changed after finding a test failure in maria.alter, where I
thought the patch broke that test. But actually, maria.alter itself
relies on somewhat broken/inconsistent server behavior.

It is the MDEV-19055 extension of the test which broke. To summarize the
broken part of the test, first, it creates a temporary table t2, adds a
new column of type DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, and adds
a constraint check on that new type:

CREATE TEMPORARY TABLE t2 (a TIME) ENGINE=Aria;
ALTER TABLE t2 ADD b DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE t2 ADD CHECK (b = 4);

The next part results in inconsistent behavior:

INSERT IGNORE INTO t2 () VALUES (),(),(),();

Prior to this patch, this would create 4 new rows, each with a zeroed
out timestamp for `b`. This is due to a the default_field not resetting
after the ALTER TABLE, thus the DEFAULT CURRENT_TIMESTAMP clause is lost
after the ALTER TABLE ADD CHECK.

With this patch, because the default_field is restored after the ALTER,
there is no affect of the INSERT IGNORE INTO t2. I.e., t2 is empty after
this insert.

This change in results further changes how an ALTER TABLE behaves later
in the test:

SET SQL_MODE= 'STRICT_ALL_TABLES';
SELECT count(a),sum(a) FROM t2;
--error ER_TRUNCATED_WRONG_VALUE
ALTER TABLE t2 CHANGE IF EXISTS d c INT;

Without this patch, there are rows in t2, and so this ALTER TABLE
results in an error. With this patch, t2 is empty, and therefore there
is no data that was truncated to warn about. It is generally bad test
practice to have a table with no rows, as it has historically masked
other bugs. So we add back a couple rows into the table to ensure it
hits additional logic. However, because the bug has been fixed, invalid
rows are not able to be inserted into the table and thereby the
ER_TRUNCATED_WRONG_VALUE error is still not thrown. So that error is
removed.

Reviewed-by: Monty <[email protected]>
Signed-off-by: Brandon Nesterenko <[email protected]>
Sergei Golubchik
MDEV-39141 MariaDB crashes in THD::THD() due to misalignment

fix my_malloc() to return 16-aligned pointers

(type_assoc_array.sp-assoc-array-64bit prints changes in memory_used,
and my_malloc() uses more memory now)
Dave Gosselin
MDEV-39441: Add dbug_print() helpers for join-related types

Introduces new dbug_print() functions for the following types:
  dbug_print(NESTED_JOIN)
  dbug_print(JOIN)
  dbug_print(TABLE_LIST)
  dbug_print(JOIN_TAB)
  dbug_print(List<Item>)

Typically pointers to instances of the given types are passed.
The dbug_print(List<Item>) is intended to show result row before
sending to client (e.g., invoke in debugger while tracing end_send)
but may work in other contexts.

These functions produce nicely formatted output, please use them
in conjunction with the formatted printfs available in GDB or LLDB:
  (gdb) printf "%s", dbug_print(join_tab)
  (lldb) p printf("%s", dbug_print(table))

Example output from dbug_print(JOIN) in LLDB.  The last line with
value 1302 is the number of characters produced by the printf
command.

(lldb) p printf("%s",dbug_print(join))
JOIN [0x15801bfe8]  table_count=3  const_tables=0
join_list 0x158018340 [1 element(s)]:
--- #0 ---
  [0x15801af10] "(nest_last_join)"  join=INNER (outer_join=0)  nested_join=0x15801b618 (elements=2)
    NESTED_JOIN [0x15801b618]
      used_tables:    0x0
      not_null_tables: 0x0
      n_tables:        0
      counter:        0
      nest_type:      1 (JOIN_OP_NEST)
      nj_map:          0x0
      join_list:
        join_list 0x15801b618 [2 element(s)]:
        --- #0 ---
          [0x15801a308] "t3"  join=LEFT (outer_join=1)  map=0x4
            ON: `test`.`t2`.`a` = `test`.`t3`.`a`
        --- #1 ---
          [0x158019b30] "(nest_last_join)"  join=INNER (outer_join=0)  nested_join=0x15801a238 (elements=2)
            NESTED_JOIN [0x15801a238]
              used_tables:    0x0
              not_null_tables: 0x0
              n_tables:        0
              counter:        0
              nest_type:      0
              nj_map:          0x0
              join_list:
                join_list 0x15801a238 [2 element(s)]:
                --- #0 ---
                  [0x1580187c0] "t1"  join=RIGHT (outer_join=2)  map=0x1
                    ON: `test`.`t1`.`a` = `test`.`t2`.`a`
                --- #1 ---
                  [0x158018f08] "t2"  join=INNER (outer_join=0)  map=0x2
(int) 1302
Sergei Petrunia
MDEV-39368: Make --replay-server-manual also provide a gdb include file.
Marko Mäkelä
MDEV-39303: Skip ibuf_upgrade() if innodb_force_recovery=6

ibuf_upgrade_needed(): Pretend that no upgrade is needed when
innodb_force_recovery=6.

srv_load_tables(): Test the least likely condition first.

srv_start(): Remove a message that is duplicating one at the start
of recv_recovery_from_checkpoint_start().

This was tested by starting up a server on an empty data directory
that had been created by MariaDB Server 10.6.

Reviewed by: Thirunarayanan Balathandayuthapani
Sergei Golubchik
MDEV-39112 fix RPAD too
Sergei Golubchik
zlib 1.3.2
Sergei Golubchik
zlib 1.3.2
Sergei Golubchik
Un-deprecate keep_files_on_create

originally (MDEV-23570) the idea was to make it TRUE and deprecate.
It cannot be deprecated when it's FALSE, but TRUE breaks
mariabackup.aria_backup where a table is altered from Aria to InnoDB
during a backup, so both t.MAD/t.MAI and t.ibd gets into a backup.
This is MDEV-38866, when it's fixed, keep_files_on_create can be
enabled by default and deprecated at last.
ParadoxV5
MDEV-38600: Warn when recreating MEMORY tables on read-only slaves

The data in MEMORY tables is temporary and is lost when the server
restarts. Thus, when these tables are rediscovered empty,
it’s well-intentioned to record TRUNCATE statements to
the binary log, complete with an increment to the `@@gtid_binlog_pos`.
However, those unaware of this mechanism may not expect this increment
and its sign of replication divergence, namely in `@@gtid_strict_mode`.

This commit adds a binary log warning
when such a table is found `implicit_emptied`.

Since general uses of memory tables may already expect this effect,
to avoid unnecessary verbosity, this warning only emits from
`@@read_only` servers with CHANGE MASTER configured. `@@read_only`
indicates that the server should not receive changes; for a slave,
it means it only expects replication to binlog changes with GTID.

Reviewed-by: Brandon Nesterenko <[email protected]>
Oleksandr Byelkin
MDEV-39287 (11.4 part) Fix compilation problems with glibc 2.43/gcc 16/fedora 44

Trick compiler with ==.
Thirunarayanan Balathandayuthapani
MDEV-37294  segv in flst::remove_complete(buf_block_t*, unsigned short, unsigned char*, mtr_t*)

Problem:
=======
During system tablespace defragmentation, extent movement occurs
in two phases: prepare and complete.
1) prepare phase validates involved pages and acquires necessary
resources.
2) complete phase performs the actual data copy.

Prepare phase fails to check whether allocating a page will
make the extent FULL. When an extent has exactly (extent_size - 1)
pages used, the prepare phase returns early without latching
the prev/next extent descriptors needed for list manipulation.

Complete phase then allocates the final page, making the
extent full, and attempts to move it from
FSEG_NOT_FULL/FSP_FREE_FRAG to FSEG_FULL/FSP_FULL_FRAG list.
This fails with an assertion because the required blocks were
never latched, causing a crash in flst::remove_complete().

Solution:
========
alloc_from_fseg_prepare(), alloc_from_free_frag_prepare():
call these function only if the extent will be full after
allocation. This makes the
prepare phase to acquire the necessary pages for FSP list manipulation

find_new_extents(): Print more revised information about moving
of extent data and destination extent also.

defragment_level(): Move get_child_pages(new_block) before committing
changes to enable proper rollback on failure. Well, this failure
is theoretically impossible (new block is exact copy of
validated old block).
Raghunandan Bhat
MDEV-37243: SP memory root protection disappears after a metadata change

Problem:
  When a stored routine involes a cursor and metadata of table on which
  the cursor is defined changes, the SP instruction has to be reparsed.
  For ex:
  CREATE OR REPLACE TABLE t1 (a INT);

  CREATE OR REPLACE FUNCTION f1() RETURNS INT
  BEGIN
    DECLARE vc INT DEFAULT 0;
    DECLARE cur CURSOR FOR SELECT a FROM t1;
    OPEN cur;
    FETCH cur INTO vc;
    CLOSE cur;
    RETURN vc;
  END;

  SELECT f1(); - first execution, sp-mem_root marked read-only on exec
  SELECT f1(); - read-only sp-mem_root
  ALTER TABLE t1 MODIFY a TEXT; - metadta change
  SELECT f1(); - reparse, rerun instr and mark new mem_root read-only

  sp_lex_instr is re-parsed after the metadata change, which sets up a
  new mem_root for reparsing. Once the instruction is re-parsed and
  re-executed(via reset_lex_and_exec_core), the new memory root assigned
  to the instruction being reparsed remains writable. This violates the
  invariant of SP memory root protection.

Fix:
  Mark the new memory root created for reparsing with read-only flag,
  after the first execution of the SP instruction.
Yuchen Pei
[fixup] Initialise order->in_field_list

Otherwise we may get

sql/table.h:239:16: runtime error: load of value 165, which is not a valid value for type 'bool'
Oleksandr Byelkin
New CC 3.4
Andrzej Jarzabek
MDEV-39122 Fix my_realpath to treat empty string as current directory

my_realpath() uses my_load_path() as a fallback. my_load_path()
replaces empty string with a current directory. But my_realpath()
didn't do it itself so the result was inconsistent: empty string was
replaced with a current directory, but if the current directory was
symlinked, symlinks were not resolved (as they were for any other,
non-empty, path, including ".").

Fix my_realpath() to treat empty string consisently with all
other paths - replace with a current dir and resolve symlinks too.