EmergencyEMERGENCY? Get 24/7 Help Now!

Percona Server 5.5.51-38.1 is now available

 | August 19, 2016 |  Posted In: Events and Announcements, MySQL, Percona Server for MySQL, Percona Software

PREVIOUS POST
NEXT POST

percona server 5.5.51-38.1Percona announces the release of Percona Server 5.5.51-38.1 on August 19, 2016. Based on MySQL 5.5.51, including all the bug fixes in it, Percona Server 5.5.51-38.1 is now the current stable release in the 5.5 series.

Percona Server is open-source and free. You can find release details of the release in the 5.5.51-38.1 milestone on Launchpad. Downloads are available here and from the Percona Software Repositories.

Bugs Fixed:
  • PAM Authentication Plugin would abort authentication while checking UNIX user group membership if there were more than a thousand members. Bug fixed #1608902.
  • PAM Authentication Plugin didn’t support spaces in the UNIX user group names. Bug fixed #1544443.
  • If DROP DATABASE would fail to delete some of the tables in the database, the partially-executed command is logged in the binlog as DROP TABLE t1, t2, ... for the tables for which drop succeeded. A slave might fail to replicate such DROP TABLE statement if there exist foreign key relationships to any of the dropped tables and the slave has a different schema from the master. Fixed by checking, on the master, whether any of the database to be dropped tables participate in a Foreign Key relationship, and fail the DROP DATABASE statement immediately. Bug fixed #1525407 (upstream #79610).
  • Percona Server 5.5 could not be built with the -DMYSQL_MAINTAINER_MODE=ON option. Bug fixed #1590454.
  • In the client library, any EINTR received during network I/O was not handled correctly. Bug fixed #1591202 (upstream #82019).
  • The included .gitignore in the percona-server source distribution had a line *.spec, which means someone trying to check in a copy of the percona-server source would be missing the spec file required to build the RPM packages. Bug fixed #1600051.
  • The fix for bug #1341067 added a call to free some of the heap memory allocated by OpenSSL. This was not safe for repeated calls if OpenSSL is linked twice through different libraries and each is trying to free the same. Bug fixed #1604676.
  • If the changed page bitmap redo log tracking thread stops due to any reason, then shutdown will wait for a long time for the log tracker thread to quit, which it never does. Bug fixed #1606821.
  • Performing slow InnoDB shutdown (innodb_fast_shutdown set to 0) could result in an incomplete purge, if a separate purge thread is running (which is a default in Percona Server). Bug fixed #1609364.
  • Due to security reasons ld_preload libraries can now only be loaded from the system directories (/usr/lib64, /usr/lib) and the MySQL installation base directory.
Other bugs fixed:

#1515591 (upstream #79249), #1612551, #1609523, #756387, #1097870, #1603073, #1606478, #1606572, #1606782, #1607224, #1607359, #1607606, #1607607, #1607671, #1608385, #1608424, #1608437, #1608515, #1608845, #1609422, #1610858, #1612084, #1612118, and #1613641.

Find the release notes for Percona Server 5.5.51-38.1 in our online documentation. Report bugs on the launchpad bug tracker.

PREVIOUS POST
NEXT POST

5 Comments

  • This new release instantly refused to start with malloc-lib set to jemalloc, while the previous versions worked as expected. What changed? No errors were being logged, and the log file itself wasn’t even being opened. This caused us an extended service outage which could have been avoided.

  • Hi,

    For security reasons ld_preload libraries can now only be loaded from system directories. It looks like this change was omitted from the change log and this announcement.

  • Hello,

    Thanks for the update! When you say system directories, are there any in particular? For example jemalloc was being loaded using:

    malloc-lib=’/usr/local/lib/libjemalloc.so’

    However, this technically is a “system directory”.

  • To answer my own question. The only dirs which work to ld_preload are:

    /usr/lib
    /usr/lib64

    I also want to mention that symlinks pointing outside of these lib dirs can be used as it doesn’t seem they’re being dereferenced. For example, I now have malloc-lib=’/usr/lib64/libjemalloc.so’, where /usr/lib64/libjemalloc.so is a symlink to /usr/local/lib/libjemalloc.so, which is also a symlink to /usr/local/lib/libjemalloc.so.2. The MySQL service however, clearly shows it loaded:

    mysqld 12853 mysql mem REG 9,0 292817 3530336 /usr/local/lib/libjemalloc.so.2

    However, I would expect the following to all work if used, and not just the two /usr/lib’s from above:

    /usr/local/lib
    /usr/local/lib64
    /lib
    /lib64

  • Thanks for reporting this, I’ll need to check the suggestion about adding the /usr/local/ as the original recommendation came from our security team.

Leave a Reply