Release Notes for MariaDB Enterprise Server 11.4.7-4

MariaDB Enterprise Server 11.4.7-4 is a Stable (GA) maintenance release of MariaDB Enterprise Server 11.4, released on 2025-06-11

circle-info

The most recent release of MariaDB Enterprise Server 11.4 is:

MariaDB Enterprise Server 11.4.7-4 is a Stable (GA) maintenance release of MariaDB Enterprise Server 11.4. This release includes a variety of fixes.

MariaDB Enterprise Server 11.4.7-4 was released on 11 Jun 2025.

Fixed Security Vulnerabilities

Changes in Storage Engines

  • This release incorporates MariaDB ColumnStore engine version 23.10.6

Notable changes

  • New user variable, analyze_max_length, default value 4G. Any field that is bigger than this value in bytes will be ignored by ANALYZE TABLE PERSISTENT to not collect statistics for long char/varchars unless it is specified in FOR COLUMNS(). (MENT-2301arrow-up-right)

  • SBOM now includes 'license' and 'copyright' information, improving security compliance and dependency tracking. (MENT-2311arrow-up-right)

  • Get option group suffix from $MARIADB_GROUP_SUFFIX in addition to $MYSQL_GROUP_SUFFIX (MDEV-21375arrow-up-right)

  • MariaDB effectively running as root CAP_DAC_OVERRIDE (MDEV-36229arrow-up-right)

  • my_getopt compares option names case sensitively (MDEV-27126arrow-up-right)

  • Systemd: Restart on OOM (MDEV-36009arrow-up-right)

  • Galera updated to 26.4.22

  • Support has been added for Oracle Linux 8 and 9

Issues Fixed

Can result in data loss

  • A multi-table UPDATE ... ORDER BY ... LIMIT statement could update the wrong rows when the ORDER BY clause was resolved by using temporary and filesort. (MDEV-35955arrow-up-right)

  • Assertion InnoDB searching row in wrong partition for multiple system versioned DELETE with same timestamp and same multistatement transaction (MDEV-36115arrow-up-right)

Can result in hang or crash

  • A query using a subquery in form:

WHERE col IN (SELECT ... LEFT JOIN tbl ON tbl.column=reference_outside_subquery)

could cause a crash in the optimizer. The essential part is that ON expression has only two kinds of references: 1.to inner side of the outer join and 2. to outside the subquery. (MDEV-32084arrow-up-right)

  • Incorrect error handling on DDL with FULLTEXT INDEX (MDEV-36061arrow-up-right)

  • ALTER TABLE…SEQUENCE does not work correctly with InnoDB (MDEV-36038arrow-up-right)

  • Race condition between log_t::resize_start() and log_t::resize_abort() (MDEV-36082arrow-up-right)

  • mariadb-backup --backup crash during innodb_undo_log_truncate=ON, innodb_encrypt_log=ON (MDEV-36152arrow-up-right)

  • Race conditions between ALTER TABLE or OPTIMIZE TABLE and the purge of transaction history were fixed. (MDEV-36122arrow-up-right)

  • Server crashes when resizing default innodb buffer pool after setting innodb-buffer-pool-chunk-size to 1M (MDEV-34677arrow-up-right)

  • Server aborts while deleting the record in spatial index (MDEV-35420arrow-up-right)

  • The server could crash when an UPDATE is about to commit concurrently with a CREATE INDEX that includes VIRTUAL columns (MDEV-36281arrow-up-right)

  • Upgrades fail on Windows (MDEV-36128arrow-up-right)

  • ASAN errors in dict_sys_t::load_table / get_foreign_key_info after failing to load a table (MDEV-33167arrow-up-right)

  • ALTER TABLE…DROP COLUMN after a failed ALTER TABLE…DROP COLUMN could lead to a server crash (MDEV-36236arrow-up-right)

  • Server crashes when creating a table using function with a return type sys_refcursor (MDEV-36409arrow-up-right)

  • Assertion `thd->lex == sp_instr_lex' failed in LEX *sp_lex_instr::parse_expr(THD *, sp_head *, LEX *) (MDEV-36377arrow-up-right)

  • Crash on `DECLARE spvar1 ROW TYPE OF cursor1` after a table recreation (MDEV-36462arrow-up-right)

  • Field pointer may be uninitialized in fill_record (MDEV-36181arrow-up-right)

  • Protocol_text allocates memory without error checking, potentially leading to server crashes. (MDEV-35640arrow-up-right)

  • A primary server could crash when a semi-sync connection is stopped, if the primary previously disabled semi-sync replication while the connection was already up (and `rpl_semi_sync_master_wait_no_slave=0`). (MDEV-36359arrow-up-right)

  • Incorrect undo logging for indexes on virtual columns whose index ID does not fit in 32 bits (MDEV-36613arrow-up-right)

  • Memory leak after failed CREATE TABLE…SELECT; crash on CREATE TABLE…SELECT that reads from multiple tables (MDEV-36504arrow-up-right)

  • Assertion `src != ((void *)0)' failed in my_casedn_8bit (MDEV-36565arrow-up-right)

  • With wsrep_ignore_apply_errors = 0, the node crashes due to assertion thd->is_error() failed in Sql_cmd_dml::prepare(), shown in the logs (MDEV-35946arrow-up-right)

  • In some cases, if there are MDL locks (for example, when LOCK TABLE is executed), a node could get stuck in the system thread due to incorrect handling of metadata locks (MDL) in server code when a transaction was BF aborted. (MDEV-35941arrow-up-right)

  • Regression after the fix for MDEV-31413arrow-up-right - sometimes the server crashes with an assertion in wsrep::transaction::before_rollback(), for example when using OPTIMIZE TABLE on an ARIA table with wsrep_osu_method=RSU. (MDEV-32631arrow-up-right)

  • SST failure occurs when gtid_strict_mode is enabled under high load, such as OLTP load is active on the primary node. A typical symptom of this error is the presence of the diagnostic "[ERROR] mariadbd: Error writing file 'binlog'", in the debug version it is also possible to crash on assertion in the wsrep::transaction::before_rollback() function with the message "Assertion `state() == s_executing || state() == s_preparing || state() == s_prepared || state() == s_must_abort || state() == s_aborting || state() == s_cert_failed || state() == s_must_replay' failed". (MDEV-34891arrow-up-right)

  • In Galera, creating sequence with a small cache leads to signal 6 error: [ERROR] WSREP: FSM: no such a transition REPLICATING -> COMMITTED. (MDEV-33850arrow-up-right)

  • Under high load wsrep internal thread may terminate due to memory pressure conditions, but this is not a crash, however in debug version user may encounter assertion in wsrep_to_isolation_begin() function with following message: "int wsrep_to_isolation_begin(THD*, const char*, const char*, const TABLE_LIST*, const Alter_info*, const key_array*, const HA_CREATE_INFO*): Assertion `(0)' failed." (MDEV-36116arrow-up-right)

  • Assertion `commit_trx' failed in innobase_commit() (ha_innodb.cc). An INSERT with sql_log_bin=0 is still replicated in Galera (per MDEV-7205arrow-up-right), despite binary logging being disabled. This results in a partial binlog bypass, requiring a two-phase commit (2PC). During 2PC, the INSERT is first prepared (entering the PREPARED state in InnoDB), and on commit, the new assertion from MDEV-24035arrow-up-right fails, causing a crash with "Assertion 'commit_trx' failed" in logs. (MDEV-35658arrow-up-right)

  • A Galera node might hang if foreign key (FK) and unique key (UK) checks are disabled on multiple appliers executing INSERTs into the same table, because InnoDB might treat these operations as bulk inserts, leading one applier to acquire a table-level lock. If another applier with a lower sequence number then waits for this lock, a deadlock can occur within Galera. Specifically, the lock holder waits for the earlier applier to commit, while the earlier applier is blocked by the lock. (MDEV-36360arrow-up-right)

  • When a sequence is used and inserts run in parallel on multiple Galera nodes, a transaction may be aborted after passing certification. If it then attempts to roll back, the binlog statement cache—which includes reserved sequence values—may be written prematurely. This causes a crash with the diagnostic "WSREP: FSM: no such a transition REPLICATING -> COMMITTED" in the logs, as the transaction is supposed to replay and only write to the binlog during the final commit. (MDEV-33589arrow-up-right)

  • A Galera node may hang due to improper mutex handling: a thread held lock_sys.wait_mutex while triggering a streaming replication rollback, which also tried to acquire THD::LOCK_thd_kill, leading to incorrect mutex usage. In debug versions, this leads to diagnostics like "safe_mutex: Found wrong usage of mutex 'wait_mutex' and 'LOCK_thd_data'", but in both debug and release versions, there is some probability that the node may hang. (MDEV-36509arrow-up-right)

  • Assertion `!level_and_file.second->being_compacted' failed in LevelCompactionBuilder::SetupInitialFiles (MDEV-16523arrow-up-right)

  • Assertion `ikey_.type == kTypeValue' failed in rocksdb::CompactionIterator::NextFromInput (MDEV-15164arrow-up-right)

  • corruption when query cache cannot allocate block (MDEV-34075arrow-up-right)

  • Stack looping and SIGSEGV in Item_args::walk_args on UPDATE (MDEV-31647arrow-up-right)

  • Server crash in find_field_in_tables, Assertion `name' failed in find_field_in_table_ref (MDEV-25012arrow-up-right)

  • Semi-sync Replica Can't Kill Dump Thread When Using SSL (MDEV-36663arrow-up-right)

  • Long server_audit_file_path causes buffer overflow (MDEV-36245arrow-up-right)

  • Server crash when inserting from derived table containing insert target table (MDEV-32086arrow-up-right)

  • Check when doing ALTER TABLE table_name sequence=1 that table can be a sequence (MDEV-36032arrow-up-right)

Can result in unexpected behaviour

Unexpected results

  • The untested ha_spider::index_first_internal constructs broken queries (MDEV-36324arrow-up-right)

  • Incorrect query result for comparisons of binary_column NOT LIKE binary_column (MDEV-36211arrow-up-right)

  • USER_STATISTICS.BUSY_TIME is in microseconds (MDEV-36586arrow-up-right)

  • When a CREATE TABLE .. SELECT errors while inserting data, a user would expect that all changes are rolled back and the table would not exist after executing the query; however, the error was accidentally ignored in the code, and the table would still exist. (MDEV-35207arrow-up-right)

  • For transactions committing in one-phase using rollback-capable engines, if binlogging fails during commit, the overall transaction would still commit, when it should roll-back. (MDEV-35506arrow-up-right)

  • Wrong results from tables with a single record and an aggregate (MDEV-35238arrow-up-right)

  • Unexpected error 1264 'Out of Range Value for Column' when inserting into ... select ... from a spider table (MDEV-35874arrow-up-right)

  • Wrong result in loose index scan (MDEV-36118arrow-up-right)

  • group by handler missing constant fields when selecting from a view (MDEV-36307arrow-up-right)

  • Tests calling the udf spider_copy_tables fail with --view-protocol (MDEV-36335arrow-up-right)

Changelog

For the complete list of changes in this release, see the changelog.

Platforms

In alignment to the enterprise lifecycle, MariaDB Enterprise Server 11.4.7-4 is provided for:

  • AlmaLinux 8 (x86_64, ARM64)

  • AlmaLinux 9 (x86_64, ARM64)

  • Debian 11 (x86_64, ARM64)

  • Debian 12 (x86_64, ARM64)

  • Microsoft Windows (x86_64) (MariaDB Enterprise Cluster excluded)

  • Oracle Linux 8 (x86_64, ARM64)

  • Oracle Linux 9 (x86_64, ARM64)

  • Red Hat Enterprise Linux 8 (x86_64, ARM64)

  • Red Hat Enterprise Linux 9 (x86_64, ARM64, PPC64LE)

  • Rocky Linux 8 (x86_64, ARM64)

  • Rocky Linux 9 (x86_64, ARM64)

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)

  • Ubuntu 22.04 (x86_64, ARM64)

  • Ubuntu 24.04 (x86_64, ARM64)

  • Microsoft Windows (x86_64) (Without MariaDB Enterprise Cluster (Galera) support)

  • Red Hat UBI 8 (x86_64, ARM64)

    • Red Hat UBI 8 is part of the Enterprise Server Docker Image. It does not support MariaDB Enterprise Cluster (Galera) or MariaDB ColumnStore.

Some components of MariaDB Enterprise Server are supported on a subset of platforms. See MariaDB Engineering Policiesarrow-up-right for details.

Installation Instructions

Upgrade Instructions

This page is: Copyright © 2025 MariaDB. All rights reserved.

spinner

Last updated

Was this helpful?