MariaDB 10.1.6 Overview and Highlights

MariaDB 10.1.6 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.1.6/

This is the 4th beta, and 7th overall, release of MariaDB 10.1. There were not many major changes in this release, but a few notable items, as well as many overall bugs fixed (I counted 156, down ~50% from 10.1.5).

Since it’s beta, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).

To me, these are the highlights:

  • RESET_MASTER is extended with TO # clause which allows one to specify the number of the first binary log. (MDEV-8469)
  • Added support for binlog_row_image=minimal for compatibility with MySQL.
  • New status variables: log_bin_basename, log_bin_index and relay_log_basename.
  • New status variables: innodb_buf_dump_status_frequency for determining how often the buffer pool dump status should be printed in the logs.
  • New status variables: Com_create_temporary_table and Com_drop_temporary_table for tracking the number of CREATE/DROP TEMPORARY TABLE statements.
  • Connect updated to 1.04.0001.
  • Mroonga updated to 5.04 (earlier versions of Mroonga did not work in 10.1).

Of course it goes without saying that do not use this for production systems since it is still only beta. However, I definitely recommend installing it on a test server and testing it out. And if you happen to be running a previous version of 10.1, then you should definitely upgrade to this latest release.

You can read more about the 10.1.6 release here:

https://mariadb.com/kb/en/mariadb-1016-release-notes/

And if interested, you can review the full list of changes in 10.1.6 (changelogs) here:

https://mariadb.com/kb/en/mariadb-1016-changelog/

Hope this helps.

MySQL 5.6.26 Overview and Highlights

MySQL 5.6.26 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.

For this release, there are 3 “Functionality Added or Changed” items, 1 “Security Fix”, and 36 other bug fixes.

Out of those other 36 bugs, 13 are InnoDB, 1 Partitioning, 3 Replication, and 19 misc. (including 3 potentially crashing bug fixes, and 1 performance-related fix) Here are the ones of note:

  • Functionality Added/Changed: Replication: When using a multi-threaded slave, each worker thread has its own queue of transactions to process. In previous MySQL versions, STOP SLAVE waited for all workers to process their entire queue. This logic has been changed so that STOP SLAVE first finds the newest transaction that was committed by any worker thread. Then, it waits for all workers to complete transactions older than that. Newer transactions are not processed. The new logic allows STOP SLAVE to complete faster in case some worker queues contain multiple transactions. (Bug #75525)
  • Functionality Added/Changed: Previously, the max_digest_length system variable controlled the maximum digest length for all server functions that computed statement digests. However, whereas the Performance Schema may need to maintain many digest values, other server functions such as MySQL Enterprise Firewall need only one digest per session. Increasing the max_digest_length value has little impact on total memory requirements for those functions, but can increase Performance Schema memory requirements significantly. To enable configuring digest length separately for the Performance Schema, its digest length is now controlled by the new performance_schema_max_digest_length system variable.
  • Functionality Added/Changed: Previously, changes to the validate_password plugin dictionary file (named by the validate_password_dictionary_file system variable) while the server was running required a restart for the server to recognize the changes. Now validate_password_dictionary_file can be set at runtime and assigning a value causes the named file to be read without a restart. In addition, two new status variables are available. validate_password_dictionary_file_last_parsed indicates when the dictionary file was last read, and validate_password_dictionary_file_words_count indicates how many words it contains. (Bug #66697)
  • Security-related: Due to the LogJam issue (https://weakdh.org/), OpenSSL has changed the Diffie-Hellman key length parameters for openssl-1.0.1n and up. OpenSSL has provided a detailed explanation at http://openssl.org/news/secadv_20150611.txt. To adopt this change in MySQL, the key length used in vio/viosslfactories.c for creating Diffie-Hellman keys has been increased from 512 to 2,048 bits. (Bug #77275)
  • InnoDB: Importing a tablespace with a full-text index resulted in an assertion when attempting to rebuild the index.
  • InnoDB: Opening a foreign key-referenced table with foreign_key_checks enabled resulted in an error when the table or database name contained special characters.
  • InnoDB: The page_zip_verify_checksum function returned false for a valid compressed page.
  • InnoDB: A failure to load a change buffer bitmap page during a concurrent delete tablespace operation caused a server exit.
  • InnoDB: After dropping a full-text search index, the hidden FTS_DOC_ID and FTS_DOC_ID_INDEX columns prevented online DDL operations. (Bug #76012)
  • InnoDB: An index record was not found on rollback due to inconsistencies in the purge_node_t structure. (Bug #70214)
  • Partitioning: In certain cases, ALTER TABLE … REBUILD PARTITION was not handled correctly when executed on a locked table.
  • Replication: If flushing the cache to the binary log failed, for example due to a disk problem, the error was not detected by the binary log group commit logic. This could cause inconsistencies between the master and the slave. The fix uses the binlog_error_action variable to decide how to handle this situation. If binlog_error_action=ABORT_SERVER, then the server aborts after informing the client with an ER_BINLOGGING_IMPOSSIBLE error. If binlog_error_action=IGNORE_ERROR, then the error is ignored and binary logging is disabled until the server is restarted again. The same is mentioned in the error log file, and the transaction is committed inside the storage engine without being added to the binary log. (Bug #76795)
  • Replication: When using GTIDs, a multi-threaded slave which had relay_log_recovery=1 and that stopped unexpectedly could encounter a relay-log-recovery cannot be executed when the slave was stopped with an error or killed in MTS mode error upon restart. The fix ensures that the relay log recovery process checks if GTIDs are in use or not. If GTIDs are in use, the multi-threaded slave recovery process uses the GTID protocol to fill any unprocessed transactions. (Bug #73397)
  • Replication: When two slaves with the same server_uuid were configured to replicate from a single master, the I/O thread of the slaves kept reconnecting and generating new relay log files without new content. In such a situation, the master now generates an error which is sent to the slave. By receiving this error from the master, the slave I/O thread does not try to reconnect, avoiding this problem. (Bug #72581)
  • Crashing Bug: Incorrect cost calculation for the semi-join Duplicate Weedout strategy could result in a server exit.
  • Crashing Bug: For large values of max_digest_length, the Performance Schema could encounter an overflow error when computing memory requirements, resulting in a server exit.
  • Crashing Bug: GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit.
  • Performance-related: When choosing join order, the optimizer could incorrectly calculate the cost of a table scan and choose a table scan over a more efficient eq_ref join. (Bug #71584)

Conclusions:

So while there were no major changes, and not too many overall bug fixes, the security fix could be an issue if you run the latest RHEL/CentOS with SSL connections + a DHE SSL cipher specifed with –ssl-cipher=DHE-RSA-… Also, some of those InnoDB bugs are nasty, especially the fulltext bugs, thus if you use InnoDB’s fulltext, I’d recommend planning for an upgrade.

The full 5.6.26 changelogs can be viewed here (which has more details about all of the bugs listed above):

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-26.html

Hope this helps. :)

MySQL 5.5.45 Overview and Highlights

MySQL 5.5.45 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were 0 “Functionality Added or Changed” items this time, 1 “Security Fix”, and just 9 bugs overall fixed.

Out of the 9 bugs, there were 3 InnoDB bugs, 1 security-related bug, and 1 potential crashing bug. Here are the ones worth noting:

  • InnoDB: An index record was not found on rollback due to inconsistencies in the purge_node_t structure.
  • InnoDB: An assertion was raised when InnoDB attempted to dereference a NULL foreign key object.
  • InnoDB: On Unix-like platforms, os_file_create_simple_no_error_handling_func and os_file_create_func opened files in different modes when innodb_flush_method was set to O_DIRECT. (Bug #76627)
  • Security-related: Due to the LogJam issue (https://weakdh.org/), OpenSSL has changed the Diffie-Hellman key length parameters for openssl-1.0.1n and up. OpenSSL has provided a detailed explanation at http://openssl.org/news/secadv_20150611.txt. To adopt this change in MySQL, the key length used in vio/viosslfactories.c for creating Diffie-Hellman keys has been increased from 512 to 2,048 bits. (Bug #77275)
  • Crashing Bug: GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit.

I don’t think I’d call any of these urgent for all (unless you run the latest RHEL/CentOS with SSL connections + a DHE SSL cipher specifed with –ssl-cipher=DHE-RSA-…), but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

For reference, the full 5.5.45 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-45.html

Hope this helps.

LDAP Authentication with MariaDB PAM Plugin

This is getting more and more common, so I wanted to provide the steps required to get LDAP authentication working with MariaDB PAM plugin.

Unless you’re already familiar with setting up the MariaDB PAM plugin, I’d first recommend getting this to work with a standard Linux user (steps 1-4), then once all is working fine, progress to the LDAP users (steps 5-10). (And if you do not want to test this for the Linux user account, then you may skip steps #2 and #3.)

  1. Enable plugin by running the following from the command line client:
    INSTALL SONAME 'auth_pam';

    You should see an entry like this afterward in SHOW PLUGINS:

    | pam | ACTIVE | AUTHENTICATION | auth_pam.so | GPL |
  2. Create the mysql user account (note it does not have a password, as it will obtain this from your Linux user, and eventually the LDAP account) and provide it with the GRANTS you want it to have:
    CREATE USER 'chris'@'localhost' IDENTIFIED VIA pam USING 'mariadb';
    GRANT ALL ON db1.* TO 'chris'@'localhost';

    Note “mariadb” is the PAM service name I’ve specified. It is good to specify this so you don’t overwrite the existing default policy (in case it is being used).

  3. Create PAM policy in “/etc/pam.d/mariadb” (ensure readable and ensure the file name, “mariadb”, matches the PAM service name you specified for your user in the above step):
    auth required pam_unix.so
    account required pam_unix.so

    (Restart MariaDB instance afterward.)

    Then, you should be able to connect via the command line with (assuming you have a Linux user ‘chris’):

    mysql -u chris -p

    This should allow you to login. Now you can move on to integrating LDAP.

  4. Verify the LDAP user exists with:
    shell> id chris

    It should return uid, gid, groups, etc.

  5. If using the MySQL client, you’ll need to enable the clear text plugin:
    [mysqld]
    pam_use_cleartext_plugin

    If you need to do this, it is recommended you begin using SSL connections, if not already.

    Also, you’ll need to reboot after this change, but wait until after step #6.

  6. We need to edit the PAM policy in “/etc/pam.d/mariadb” to:
    auth required pam_ldap.so
    account required pam_ldap.so

    (We’re basically just replacing “pam_unix.so” with “pam_ldap.so”.)

    Now, restart MariaDB.

  7. Next, you need to ensure that you have libpam-ldap/openldap installed (so you have “pam_ldap.so”, that is the key). You can install this on RedHat/CentOS with the following:
    # yum install openldap openldap-clients
  8. After that, you’ll need to configure /etc/ldap.conf. Here is a sample configuration:
    debug 10 # set debug level only during the initial configuration
    base dc=corp,dc=company_name,dc=com
    binddn cn=service_account,OU=Service Accounts,OU=US Security,DC=corp,DC=company_name,DC=com
    bindpw <password>
    timelimit 120
    idle_timelimit 3600
    uri ldaps://<LDAP URL>:<LDAP PORT>

    And if using Active Directory, you should also add these lines:

    pam_login_attribute samaccountname
    pam_member_attribute member
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_attribute uid sAMAccountName
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute shadowLastChange pwdLastSet
    nss_map_objectclass posixGroup group
    nss_map_attribute uniqueMember member
    pam_login_attribute sAMAccountName
    pam_filter objectclass=User
    pam_password ad

    Note I obtained the sample ldap.conf from this Alexander Rubin post.

  9. After that, make sure you can connect to ldap and that you can search ldap with ldapsearch, which you can verify with:
    shell> telnet <ldap server> <ldap password> (this should report "connected")
    shell> ldapsearch –w <password for bind user> -x –D 'cn=USER,OU=People...' "(&(ObjectClass=user)(cn=USERNAME))"
  10. After this, things should be all set up, as the plugin is installed properly, the user has been created in MariaDB, we’ve installed pam_ldap.so, we’ve updated /etc/pam.d/mariadb to use the pam_ldap.so instead of the pam_unix.so, and created the appropriate ldap.conf. Thus you should be able to login with the following (this time assuming “chris” is an LDAP user account):
    mysql -u chris -p
  11. If you want to know more about user mapping, you should read this post by Geoff Montee as well as this post by Alexander Rubin.

    I hope this helps.

MariaDB 10.0.20 Overview and Highlights

MariaDB 10.0.20 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.20/

This is the eleventh GA release of MariaDB 10.0, and 21st overall release of MariaDB 10.0.

There were no major functionality changes, but there was one security fix, 6 crashing bugs fixed, some general upstream fixes, and quite a few bug fixes, so let me cover the highlights:

  • Security Fix: Client command line option –ssl-verify-server-cert (and MYSQL_OPT_SSL_VERIFY_SERVER_CERT option of the client API) when used together with –ssl will ensure that the established connection is SSL-encrypted and the MariaDB server has a valid certificate. This fixes CVE-2015-3152.
  • Crashing Bug: mysql_upgrade crashes the server with REPAIR VIEW (MDEV-8115).
  • Crashing Bug: Server crashes in intern_plugin_lock on concurrent installing semisync plugin and setting rpl_semi_sync_master_enabled (MDEV-363).
  • Crashing Bug: Server crash on updates with joins still on 10.0.18 (MDEV-8114).
  • Crashing Bug: Too large scale in DECIMAL dynamic column getter crashes mysqld (MDEV-7505).
  • Crashing Bug: Server crashes in get_server_from_table_to_cache on empty name (MDEV-8224).
  • Crashing Bug: FreeBSD-specific bug that caused a segfault on FreeBSD 10.1 x86 (MDEV-7398).
  • XtraDB upgraded to 5.6.24-72.2
  • InnoDB updated to InnoDB-5.6.25
  • Performance Schema updated to 5.6.25
  • TokuDB upgraded to 7.5.7

Given the security fix, you may want to consider upgrading if that particular CVE is of concern to you. Also, please review the crashing bugs to see if they might affect you, and upgrade if so. Also, if running TokuDB, XtraDB, InnoDB, or Performance Schema, you may also want to benefit from those fixes, as well as the new MariaDB fixes (139 in all).

You can read more about the 10.0.20 release here:

https://mariadb.com/kb/en/mariadb-10020-release-notes/

And if interested, you can review the full list of changes in 10.0.20 (changelogs) here:

https://mariadb.com/kb/en/mariadb-10020-changelog/

Hope this helps.

MariaDB 5.5.44 Overview and Highlights

MariaDB 5.5.44 was recently released (it is the latest MariaDB 5.5), and is available for download here:

https://downloads.mariadb.org/mariadb/5.5.44/

This is a maintenance release, and no major changes, so there are only several noteworthy items (but one of those being a security fix and five potential crashing bug):

  • Security Fix: Client command line option –ssl-verify-server-cert (and MYSQL_OPT_SSL_VERIFY_SERVER_CERT option of the client API) when used together with –ssl will ensure that the established connection is SSL-encrypted and the MariaDB server has a valid certificate. This fixes CVE-2015-3152.
  • Crashing Bug: mysql_upgrade crashes the server with REPAIR VIEW (MDEV-8115).
  • Crashing Bug: Server crashes in intern_plugin_lock on concurrent installing semisync plugin and setting rpl_semi_sync_master_enabled (MDEV-363).
  • Crashing Bug: Server crash on updates with joins still on 10.0.18 (MDEV-8114).
  • Crashing Bug: Too large scale in DECIMAL dynamic column getter crashes mysqld (MDEV-7505).
  • Crashing Bug: Server crashes in get_server_from_table_to_cache on empty name (MDEV-8224).
  • XtraDB upgraded to 5.5.42-37.2
  • TokuDB upgraded to 7.5.7

Given the security fix, you may want to review the CVE to see if this is something you need to address. Also, please review the crashing bugs to see if they might affect you, and upgrade if so. Also, if running TokuDB or XtraDB, you may also want to benefit from those fixes, as well as the new MariaDB fixes (59 in all).

If interested, the official MariaDB 5.5.44 release notes are here:

https://mariadb.com/kb/en/mariadb/development/release-notes/mariadb-5544-release-notes/

And the full list of fixed bugs and changes in MariaDB 5.5.44 can be found here:

https://mariadb.com/kb/en/mariadb/development/changelogs/mariadb-5544-changelog/

Hope this helps.

MariaDB 10.1.5 Overview and Highlights

MariaDB 10.1.5 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.1.5/

This is the 3rd beta, and 6th overall, release of MariaDB 10.1. There were not many major changes in this release, but a few notable items, as well as many overall bugs fixed (I counted 306).

Since it’s beta, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).

To me, these are the highlights:

Of course it goes without saying that do not use this for production systems since it is still only beta. However, I definitely recommend installing it on a test server and testing it out. And if you happen to be running a previous version of 10.1, then you should definitely upgrade to this latest release.

You can read more about the 10.1.5 release here:

https://mariadb.com/kb/en/mariadb-1015-release-notes/

And if interested, you can review the full list of changes in 10.1.5 (changelogs) here:

https://mariadb.com/kb/en/mariadb-1015-changelog/

Hope this helps.

MySQL 5.6.25 Overview and Highlights

MySQL 5.6.25 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.

For this release, there are 2 “Functionality Added or Changed” items of note:

  • Functionality Added/Changed: MySQL distributions now include an innodb_stress suite of test cases. Thanks to Mark Callaghan for the contribution. (Bug #76347)
  • Functionality Added/Changed: my_print_defaults now masks passwords. To display passwords in cleartext, use the new –show option.

In addition to those, there were 55 other bug fixes:

  • 10 InnoDB
  •   8 Replication
  •   3 Partitioning (one overlaps w/ an InnoDB bug fix)
  • 35 Miscellaneous (and 6 of those were specifically for “MySQL Enterprise Firewall”)

The highlights for me are 5 of the replication bugs, 1 partitioning bug, 1 performance-related bug, 1 wrong results bug, and 9 crashing bugs:

  • Replication: When using semisynchronous replication performance was degrading when the number of threads increased beyond a certain threshold. To improve performance, now only the thread which is committing is responsible for deleting the active transaction node. All other operations do not touch this active transaction list. (Bug #75570)
  • Replication: When binary logging was enabled, using stored functions and triggers resulting in a long running procedure that inserted many records caused the memory use to increase rapidly. This was due to memory being allocated per variable. The fix ensures that in such a situation, memory is allocated once and the same memory is reused. (Bug #75879)
  • Replication: If an error was encountered while adding a GTID to the received GTID set, the log lock was not being correctly released. This could cause a deadlock. (Bug #75781)
  • Replication: When master_info_repository=TABLE the receiver thread stores received event information in a table. The memory used in the process of updating the table was not being freed correctly and this could lead to an out of memory error. The fix ensures that after an event is flushed to the relay log file by a receiver thread, the memory used is freed. (Bug #72885, Bug #69848)
  • Replication: Using mysqlbinlog to process log events greater than 1.6GB failed with an out of memory error. This was caused by an internal error converting the length variable. The fix upgrades the length variable to avoid overflow in both encoding and decoding functions. (Bug #74734)
  • Partitioning: Executing an ALTER TABLE on a partitioned table on which a write lock was in effect could cause subsequent SQL statements on this table to fail. (Bug #74288).
  • Performance-related: Certain queries for the INFORMATION_SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug #72322)
  • Incorrect Results: Queries that included a HAVING clause based on nondeterministic functions could produce incorrect results. (Bug #69638)
  • Crashing Bug: For small values of the read_rnd_buffer_size system variable, internal caching of temporary results could fail and cause query execution failure.
  • Crashing Bug: A failed FLUSH PRIVILEGES statement followed by statements to create or drop accounts could cause a server exit.
  • Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
  • Crashing Bug: For join queries with a large number of tables, the server could exit converting the join to a semi-join.
  • Crashing Bug: Deleting rows from mysql.user following by granting privileges to a new account could result in a server exit.
  • Crashing Bug: Within a stored procedure, access to view columns after DDL or FLUSH TABLES statements in the procedure could cause a server exit.
  • Crashing Bug: Execution of certain BINLOG statements while temporary tables were open by HANDLER statements could cause a server exit.
  • Crashing Bug: For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit.
  • Crashing Bug: Specifying –general_log_file= (with an empty value) at server startup caused the server to fail and exit.

Conclusions:

So while there were no major changes, the partitioning fix could fix a potentially serious issue if you think you might encounter it (some partitioning use-cases involve frequent ALTERs), the replication fixes could potentially be important for you, and the numerous crashing (and performance-related & wrong results) bugs are important if you’re performing the operations that trigger them. So read through these, and if you’ll be affected by any of the above, or think you might be, then I’d recommend upgrading.

On a side note, there are several serious “MySQL Enterprise Firewall” bug fixes in this release, which I omitted above since the general public doesn’t have access to it, but if you are using it, you should upgrade due to the number of potentially serious bugs that exist in prior versions.

The full 5.6.25 changelogs can be viewed here (which has more details about all of the bugs listed above):

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-25.html

Hope this helps. :)

MySQL 5.5.44 Overview and Highlights

MySQL 5.5.44 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were 0 “Functionality Added or Changed” items this time, and just 15 overall bugs fixed.

Out of the 15 bugs, there were 5 InnoDB bugs (1 of which also spans partitioning), 1 security-related bug, 1 performance-related, and 3 additional potential crashing bugs. Here are the ones worth noting:

  • InnoDB: An assertion was raised on shutdown due to XA PREPARE transactions holding explicit locks.
  • InnoDB: Removal of a foreign key object from the data dictionary cache during error handling caused the server to exit.
  • InnoDB: SHOW ENGINE INNODB STATUS output showed negative reservation and signal count values due to a counter overflow error.
  • InnoDB: Estimates that were too low for the size of merge chunks in the result sorting algorithm caused a server exit.
  • InnoDB; Partitioning: The CREATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows the correct table creation time for partitioned InnoDB tables. The CREATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows the correct partition creation time for a partition of partitioned InnoDB tables. The UPDATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows when a partitioned InnoDB table was last updated by an INSERT, DELETE, or UPDATE. The UPDATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows when a partition of a partitioned InnoDB table was last updated. (Bug #69990)
  • Security-related: A user with a name of event_scheduler could view the Event Scheduler process list without the PROCESS privilege.
  • Performance-related: Certain queries for the INFORMATION_SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug #72322)
  • Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
  • Crashing Bug: Under certain conditions, the libedit command-line library could write outside an array boundary and cause a client program crash.
  • Crashing Bug: For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit.

I don’t think I’d call any of these urgent for all, but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

For reference, the full 5.5.44 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-44.html

Hope this helps.

MariaDB 10.1.4 Overview and Highlights

MariaDB 10.1.4 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.1.4/

This is the 2nd beta, and 5th overall, release of MariaDB 10.1. Now that it is beta, there were not as many major changes in this release (compared to 10.1.3), but there were a few notable items as well as many overall bugs fixed (I counted 367).

Since it’s beta, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).

To me, these are the highlights:

Of course it goes without saying that do not use this for production systems as it is only the 2nd beta release of 10.1. However, I definitely recommend installing it on a test server and testing it out. And if you happen to be running a previous version of 10.1, then you should definitely upgrade to this latest release.

You can read more about the 10.1.4 release here:

https://mariadb.com/kb/en/mariadb-1014-release-notes/

And if interested, you can review the full list of changes in 10.1.4 (changelogs) here:

https://mariadb.com/kb/en/mariadb-1014-changelog/

Hope this helps.