Release Notes for MariaDB Enterprise Server 10.4.12-6

During a server restart InnoDB recovery could encounter an out-of-memory condition. A restart was only possible after increasing innodb_buffer_pool_size . (MDEV-19176)

On a rollback of a large insert or update, or during a background task to purge transaction history after a large update or delete, the server could hang. (MDEV-21509)

On a rollback or during a background task to purge transaction history due to a SPATIAL INDEX, the server could hang. (MDEV-21512)

Crashes could occur rarely when using ALTER TABLE ... IMPORT TABLESPACE (MDEV-21513)

Possible server crash if binlog_checksum=CRC32 (default) is set and if the value for parameter pos in SHOW BINLOG EVENTS FROM pos does not point to the beginning of an event in the binary log. (MDEV-18046)

A replication primary (master) running in semi-sync mode could crash when RESET MASTER is executed and the replica reconnects using the GTID protocol. (MDEV-19376)

MariaDB Enterprise Backup could encounter a deadlock if a backup is taken from a replica with slave-parallel-threads is set to a value greater than 0 (MDEV-21255)

MariaDB Enterprise Backup could crash when used in combination with FLUSH TABLES and UNLOCK TABLES (MENT-438)

The aria_pack utility crashed when running an offline datafile compress on a table. (MDEV-14183)

Dropping a partition with wsrep_OSU_method=RSU and SESSION sql_log_bin=0 caused the MariaDB Enterprise Cluster (Galera) node to hang. (MDEV-21189)

Shutdown of a replica (slave) Server could hang when slave-parallel-threads is set to a value greater than 0 (MDEV-20821)

Using SET STATEMENT max_statement_time to set a timeout for the statement resulted in a crash. (MENT-634)

Querying the wsrep_on system status variable after enabling Galera Cluster Replication in MariaDB Enterprise Cluster for a running server could result in a crash. (MENT-633)

Executing TRUNCATE or OPTIMIZE on InnoDB tables could lead to an unexpected SQL Error (1118): Row size too large, when innodb_strict_mode=ON (default). (MDEV-21429)

Queries which use window functions and implicit grouping could return wrong results. (MDEV-21318)

Queries which use DISTINCT COUNT(*) OVER() in the expression returned wrong results. (MDEV-16579)

Inefficient thread handling in the thread pool, impacting any application that uses the thread pool. (MDEV-21343)

The MariaDB Enterprise Server config file mariadb-enterprise.cnf was not registered as a config file in RPM packages. (MENT-591)

ALTER USER IF EXISTS generated a SQL syntax error. (MENT-643)

A query using GROUP BY with an expression containing a field of a view could return wrong results. (MDEV-20922)

Running the script mysql_tzinfo_to_sql for MariaDB Enterprise Cluster could result in inconsistent timezone information across different nodes. (MDEV-21209)

Using the --use-memory option with mariabackup would cause it to run out of memory. (MDEV-20679)

For MariaDB Enterprise Cluster (Galera Library 26.4.4):

• GCS delivered a JOIN message even if the node was in a DONOR state.

• GCache could contain mixed histories from different clusters.

• GComm socket timestamping/liveness checking produced false positives during replication of large transactions, which caused excessive amounts of broken connections.

• Large transactions were able to monopolize bandwidth when segmentation was configured, causing delayed in messages relayed by segment representative. The fix implements fair queuing of messages.

• Due to a bug in quorum computation, two primary conflicting primary components were formed when the group merged and partitioned again while the new primary view was forming.

A range plan was not always used for multi-join queries. (MDEV-21383)

An ALTER TABLE on an InnoDB table adding a new first column which is used to define system versioning period could lead to unexpected errors. This only happened when the transaction-based system version was used. (MDEV-18865, MDEV-18875)

Server could not be started when lc_messages is set in a config file. (MENT-625)