1.148.  mysql

an error in the mysqld init script caused the MySQL service to not wait correctly if the socket file specified in /etc/my.cnf was anything other than the default. This caused MySQL to return an erroneous "[FAILED]" message. With this update, /etc/init.d/mysqld has been corrected, MySQL waits correctly and the erroneous error message no longer presents. (BZ#435494)

when slave DBs rotated relay logs, the file was deleted and the relay log index file was then edited. If the slave shut down before the index file was edited, said file contained a reference to a now non-existent relay log. In some circumstances, this could cause a race condition or a replication failure when restarting slave DB. With this update, the relay log index file is updated before the relay log file is deleted, ensuring the race condition or replication failure can not occur. (BZ#448534)

the mysqld init script did not check that mysql ran as the mysql user. It also did not explicitly initialize the MySQL database in the directory specified in my.conf. With this update, both these oversights have been rectified. Note: the absence of these checks did not prevent a default MySQL installation initializing successfully. (BZ#450178)

in one reported instance, upgrading from MySQL 5.0.22 to MySQL 5.0.45 caused a large database to repeatedly crash on launch. The crashes ceased when MySQL was further upgraded to version 5.0.51b. This updated package upgrades MySQL to version 5.0.77, which incorporates the changes made in 5.0.51b. (BZ#452824)

as of MySQL 5.0.42, DATE values are compared as ints not strings. Consequent to this, using DATE() in a WHERE clause did not return any records after a NULL value. The null_value flag was not reset, causing all values following the first NULL value encountered to also be treated as NULL. With this update, the flag is reset correctly and the DATE() function returns records as expected. (BZ#453156)

the tmpdir variable was not honored for temporary tables created for filesorts. .frm files were created correctly but data files were written to the working directory. Depending on the working directory's location, MySQL could slow to a crawl or even appear to hang. With this update, the tmpdir variable is honored as expected. (BZ#455619)

for large enough query caches, invalidating a data subset took too long, effectively freezing the server. Dictionary access requests are now limited to 0.1 seconds. For longer requests, the system falls back to ordinary statement execution. Note: this does not work for query cache invalidations issued by DROP, ALTER or RENAME TABLE operations. (BZ#456875)

in a stored function or trigger, when InnoDB detected a deadlock it attempted a rollback and displayed an incorrect ERROR 1422 message. In practice this meant, if two concurrent transactions updated the same table, the second would display the erroneous error. InnoDB now returns an error under these conditions and does not attempt a rollback. (BZ#457218)

equivalent paths in MySQL config files (eg, ~/.my.cnf and SYSCONFDIR/my.cnf), could be read twice at startup. SYSCONFDIR/my.cnf was also read last, so ~/.my.cnf did not override as expected. Paths are now normalized and duplicates removed before the list is read; also, SYSCONDIR/my.cnf is now read before ~/.my.cnf. (BZ#462534)

when MyISAM keys were fetched, a key block pointer was copied to the end of the key buffer but the pointer length was not accounted for when the buffer size was calculated. This could cause memory overwrites which, in turn, lead to unpredictable results. Given this unpredictability there is no simple test case. One known consequence, however, is queries that, in some cases, produced a result set using ORDER BY ASC but returned no results when using ORDER BY DESC. With this update, the key buffer size has been increased by the length of the key block pointer. Memory overwrites no longer occur and, consequently, queries return results as expected when ORDER BY DESC is used. (BZ#470036)

when a client connection exited without calling mysql_close(), the aborted_threads variable was updated twice and the aborted_clients status variable was consequently incremented twice. With this update, aborted_threads is updated in only one place, preventing the second, erroneous, aborted_clients incrementation. (BZ#479615)