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
f8015f84c819...
f8015f84c819d8eca7c5372b2d29f7a397e16d0a
Sergei Golubchik
cleanup: rename an argument
f2438bce7072...
f2438bce7072945311705ebefd3f6c1401506cac
Oleg Smirnov
MDEV-39349 NO_INDEX hint using QB_NAME doesn't work inside VIEWs
f1625339f5af...
f1625339f5af09972c842fb8367b98b940babe6d
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
ebc5f5cfa3b8...
ebc5f5cfa3b84ba46a5828eabd0db7025574b13c
Sergei Petrunia
More --disable_replay commands (3).
e2f91f428957...
e2f91f42895718f8610bf327a016913085be8447
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.
dd5cca14e9be...
dd5cca14e9beed72d4ad35e6bb2443f9880315f7
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.
d86a1f9712bf...
d86a1f9712bfd96cda6d7dafe18a990fc22d6eea
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]>
d49e84d5a45d...
d49e84d5a45d38bdd5c6d3f59373d13df7f159f3
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]>
cee3ff42f690...
cee3ff42f69015aefd89d2dfd1ac3c25f489d295
Sergei Golubchik
MDEV-38550 post-merge fixes

* update to the fixed libmariadb
* update test to match, remove useless INSTALL PLUGIN
* address remaining review comments
ceabbd549241...
ceabbd5492415fe5b77b2f1cb1e17dacd4bb40ab
Oleksandr Byelkin
zlib 1.3.2
caac2d7ed340...
caac2d7ed340cbf441ce877d00cea3789accf9e4
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]>
c6fadc6e337f...
c6fadc6e337f5503d629761b47abaa553fc966ae
Yuchen Pei
Merge branch '10.11' into 11.4
a186019173e9...
a186019173e9f19193c02266858b86df0e085836
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
9f00ff0f5844...
9f00ff0f584479701c3190fe6d50d7caa4591b51
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
9a8cf00fb47d...
9a8cf00fb47ddd7a31ad62cfd282bf342e786a12
ParadoxV5
Merge branch '10.11' into MDEV-38600
9936b16e12da...
9936b16e12da94f86317d2997c36b6fb7261703e
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]>
986a260c85e4...
986a260c85e4c4506fd57ed6c3af25ccd6eca63a
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.
8e26fd8efde8...
8e26fd8efde8124251ae295729add13443743be6
Sergei Golubchik
zlib 1.3.2
87ddc03f6b35...
87ddc03f6b35dbb87748410baf2f94881a2758a1
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.
7e64fdba19db...
7e64fdba19db5a4b4e5d2c2b625f6ded7b8e1d6d
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)
7c30bffd54bf...
7c30bffd54bf8f7e24a93080389d6b28b6d14869
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.
6e5bf40f63cc...
6e5bf40f63cc0a242ac310840088f37679d00583
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
658f83016cc1...
658f83016cc1b03c525d975281535ba55e16558c
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.
5b665f0069ba...
5b665f0069bada02ccd0be6bcbbc563d343667cd
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]>
56a7222f75e7...
56a7222f75e7a8846c9903c9b3defc4e4a595c7d
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)
5643cdc472e6...
5643cdc472e6603c1e053e3723e182a6edf6c504
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
41887368d91d...
41887368d91db1f7fbd07f2c301dfb26a6d34af6
Sergei Petrunia
MDEV-39368: Make --replay-server-manual also provide a gdb include file.
39edbbaf8ff5...
39edbbaf8ff528ccb5691532577880b569b2779e
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
375809cd5dbf...
375809cd5dbf9a109df502d5f476eb2d458d0447
Sergei Golubchik
MDEV-39112 fix RPAD too
3730b92be0d2...
3730b92be0d2f70c9b612bbcc3be18e5dfb22c10
Sergei Golubchik
zlib 1.3.2
32c1a8d68469...
32c1a8d68469b14cf3505270c9c4a6616d4a2cfb
Sergei Golubchik
zlib 1.3.2
1f95e78ba0b6...
1f95e78ba0b6b34ee463aa27218dfd25674ec934
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.
16a25d1d8c57...
16a25d1d8c571de0a5b73218a6fac3a75dcbb749
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]>
11f408bd3b38...
11f408bd3b38577e7f7b54634e4a18613c74ed70
Oleksandr Byelkin
MDEV-39287 (11.4 part) Fix compilation problems with glibc 2.43/gcc 16/fedora 44

Trick compiler with ==.
0da0bf2cfc42...
0da0bf2cfc4248bd9aca6b58e2fd1d1ebfebce10
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).
0d9db6bbcc55...
0d9db6bbcc5532e0bde0a63e5991cb5ebee060eb
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.
09eeaa7adbe6...
09eeaa7adbe6d22152ef6df7e3b1758db6480262
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'
0339ab544ea9...
0339ab544ea95869957f3f793976f85c74ee8e17
Oleksandr Byelkin
New CC 3.4
003c3b24f0d9...
003c3b24f0d9bb19a04a6a57a9166ccef03b4b74
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.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Sat 25 Apr 2026 10:35:23 (UTC)