Joerg Bruehe wrote: > Hi, > > > MySQL 4.1.21, a new version of the popular Open Source Database > Management System, has been released. The Community Edition is now > available in source and binary form for a number of platforms from our > download pages at > http://dev.mysql.com/downloads/ and mirror sites. > > Note that not all mirror sites may be up to date at this point in time - > if you can't find this version on some mirror, please try again later or > choose another download site. > > This is a bugfix release for the recent production release family. > > This section documents all changes and bug fixes that have been > applied since the last official MySQL release. If you would like > to receive more fine-grained and personalized update alerts about > fixes that are relevant to the version and features you use, > please consider subscribing to MySQL Network (a commercial MySQL > offering). For more details please see > http://www.mysql.com/network/advisors.html. > > We welcome and appreciate your feedback! > > > News from the ChangeLog: > > Functionality added or changed: > * For spatial data types, the server formerly returned these as > VARSTRING values with a binary collation. Now the server > returns spatial values as BLOB values. > (Bug#10166: http://bugs.mysql.com/10166) > * Added the --set-charset option to mysqlbinlog to allow the > character set to be specified for processing binary log files. > (Bug#18351: http://bugs.mysql.com/18351) > * For a table with an AUTO_INCREMENT column, SHOW CREATE TABLE > now shows the next AUTO_INCREMENT value to be generated. > (Bug#19025: http://bugs.mysql.com/19025) > * The mysqldumpslow script has been moved from client RPM > packages to server RPM packages. This corrects a problem where > mysqldumpslow could not be used with a client-only RPM > install, because it depends on my_print_defaults which is in > the server RPM. (Bug#20216: http://bugs.mysql.com/20216) > > Bugs fixed: > * Security fix: If a user has access to MyISAM table t, that > user can create a MERGE table m that accesses t. However, if > the user's privileges on t are subsequently revoked, the user > can continue to access t by doing so through m. If this > behavior is undesirable, you can start the server with the new > --skip-merge option to disable the MERGE storage engine. > (Bug#15195: http://bugs.mysql.com/15195) > * Security fix: Invalid arguments to DATE_FORMAT() caused a > server crash. (CVE-2006-3469 > (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3469), > Bug#20729: http://bugs.mysql.com/20729) > Thanks to Jean-David Maillefer for discovering and reporting > this problem to the Debian project and to Christian Hammers > from the Debian Team for notifying us of it. > * Failure to account for a NULL table pointer on big-endian > machines could cause a server crash during type conversion. > (Bug#21135: http://bugs.mysql.com/21135) > * Some memory leaks in the libmysqld embedded server were > corrected. (Bug#16107: http://bugs.mysql.com/16107) > * When mysqldump disabled keys and locked a MyISAM table, the > lock operation happened second. If another client performed a > query on the table in the interim, it could take a long time > due to indexes not being used. Now the lock operation happens > first. (Bug#15977: http://bugs.mysql.com/15977) > * The length of the pattern string prefix for LIKE operations > was calculated incorrectly for multi-byte character sets. As a > result, the the scanned range was wider than necessary if the > prefix contained any multi-byte characters. > (Bug#16674: http://bugs.mysql.com/16674, > Bug#18359: http://bugs.mysql.com/18359) > * For very complex SELECT statements could create temporary > tables that were too big, but for which the temporary files > did not get removed, causing subsequent queries to fail. > (Bug#11824: http://bugs.mysql.com/11824) > * Using SELECT and a table join while running a concurrent > INSERT operation would join incorrect rows. > (Bug#14400: http://bugs.mysql.com/14400) > * Using SELECT on a corrupt table using the dynamic record > format could cause a server crash. > (Bug#19835: http://bugs.mysql.com/19835) > * Checking a spatial table (using CHECK TABLE) with an index and > only one row would indicate a table corruption. > (Bug#17877: http://bugs.mysql.com/17877) > * For SELECT ... FOR UPDATE statements that used DISTINCT or > GROUP BY over all key parts of a unique index (or primary > key), the optimizer unnecessarily created a temporary table, > thus losing the linkage to the underlying unique index values. > This caused a Result set not updatable error. (The temporary > table is unnecessary because under these circumstances the > distinct or grouped columns must also be unique.) > (Bug#16458: http://bugs.mysql.com/16458) > * Concatenating the results of multiple constant subselects > produced incorrect results. > (Bug#16716: http://bugs.mysql.com/16716) > * The use of MIN() and MAX() on columns with a partial index > produced incorrect results in some queries. > (Bug#18206: http://bugs.mysql.com/18206) > * Use of MIN() or MAX() with GROUP BY on a ucs2 column could > cause a server crash. (Bug#20076: http://bugs.mysql.com/20076) > * INSERT INTO ... SELECT ... LIMIT 1 could be slow because the > LIMIT was ignored when selecting candidate rows. > (Bug#9676: http://bugs.mysql.com/9676) > * NDB Cluster: When attempting to restart the cluster following > a data import, the cluster would fail during Phase 4 of the > restart with Error 2334: Job buffer congestion. > (Bug#20774: http://bugs.mysql.com/20774) > * NDB Cluster: A node failure during a scan could sometime cause > the node to crash when restarting too quickly following the > failure. (Bug#20197: http://bugs.mysql.com/20197) > * NDB Cluster: It was possible to use port numbers greater than > 65535 for ServerPort in the config.ini file. > (Bug#19164: http://bugs.mysql.com/19164) > * The omission of leading zeros in dates could lead to erroneous > results when these were compared with the output of certain > date and time functions. > (Bug#16377: http://bugs.mysql.com/16377) > * Certain queries having a WHERE clause that included conditions > on multi-part keys with more than 2 key parts could produce > incorrect results and send [Note] Use_count: Wrong count for > key at... messages to STDERR. > (Bug#16168: http://bugs.mysql.com/16168) > * An invalid comparison between keys in partial indexes over > multi-byte character fields could lead to incorrect result > sets if the selected query execution plan used a range scan by > a partial index over a UTF8 character field. This also caused > incorrect results under similar circumstances with many other > character sets. (Bug#14896: http://bugs.mysql.com/14896) > * NDB Cluster: The cluster's data nodes would fail while trying > to load data when NoOfFrangmentLogFiles was equal to 1. > (Bug#19894: http://bugs.mysql.com/19894) > * NDB Cluster: A problem with error handling when > ndb_use_exact_count was enabled could lead to incorrect values > returned from queries using COUNT(). A warning is now returned > in such cases. (Bug#19202: http://bugs.mysql.com/19202) > * NDB Cluster: LOAD DATA LOCAL failed to ignore duplicate keys > in Cluster tables. (Bug#19496: http://bugs.mysql.com/19496) > * NDB Cluster: Repeated CREATE - INSERT - DROP operations tables > could in some circumstances cause the MySQL table definition > cache to become corrupt, so that some mysqld processes could > access table information but others could not. > (Bug#18595: http://bugs.mysql.com/18595) > * NDB Cluster: The mgm client command ALL CLUSTERLOG > STATISTICS=15; had no effect. > (Bug#20336: http://bugs.mysql.com/20336) > * NDB Cluster: TRUNCATE TABLE failed to reset the AUTO_INCREMENT > counter. (Bug#18864: http://bugs.mysql.com/18864) > * NDB Cluster: SELECT ... FOR UPDATE failed to lock the selected > rows. (Bug#18184: http://bugs.mysql.com/18184) > * NDB Cluster: The failure of a data node when preparing to > commit a transaction (that is, while the node's status was > CS_PREPARE_TO_COMMIT) could cause the failure of other cluster > data nodes. (Bug#20185: http://bugs.mysql.com/20185) > * NDB Cluster: Renaming a table in such a way as to move it to > to a different database failed to move the table's indexes. > (Bug#19967: http://bugs.mysql.com/19967) > * NDB Cluster: Resources for unique indexes on Cluster table > columns were incorrectly allocated, so that only one-fourth as > many unique indexes as indicated by the value of > UniqueHashIndexes could be created. > (Bug#19623: http://bugs.mysql.com/19623) > * NDB Cluster (NDBAPI): On big-endian platforms, > NdbOperation::write_attr() did not update 32-bit fields > correctly. (Bug#19537: http://bugs.mysql.com/19537) > * NDB Cluster: Some queries having a WHERE clause of the form > c1=val1 OR c2 LIKE 'val2' were not evaluated correctly. (Bug # > 17421) > * NDB Cluster: Using "stale" mysqld .FRM files could cause a > newly-restored cluster to fail. This situation could arise > when restarting a MySQL Cluster using the --intial option > while leaving connected mysqld processes running. > (Bug#16875: http://bugs.mysql.com/16875) > * NDB Cluster: Repeated use of the SHOW and ALL STATUS commands > in the ndb_mgm client could cause the mgmd process to crash. > (Bug#18591: http://bugs.mysql.com/18591) > * NDB Cluster: An issue with ndb_mgmd prevented more than 27 > mysqld processes from connecting to a single cluster at one > time. (Bug#17150: http://bugs.mysql.com/17150) > * NDB Cluster: Data node failures could cause excessive CPU > usage by ndb_mgmd. (Bug#13987: http://bugs.mysql.com/13987) > * NDB Cluster: TRUNCATE failed on tables having BLOB or TEXT > columns with the error Lock wait timeout exceeded. > (Bug#19201: http://bugs.mysql.com/19201) > * A cast problem caused incorrect results for prepared > statements that returned float values when MySQL was compiled > with gcc 4.0. (Bug#19694: http://bugs.mysql.com/19694) > * Improper character set initialization in the embedded server > could result in a server crash. > (Bug#20318: http://bugs.mysql.com/20318) > * Some queries that used ORDER BY and LIMIT performed quickly in > MySQL 3.23, but slowly in MySQL 4.x/5.x due to an optimizer > problem. (Bug#4981: http://bugs.mysql.com/4981) > * Queries using an indexed column as the argument for the MIN() > and MAX() functions following an ALTER TABLE .. DISABLE KEYS > statement returned Got error 124 from storage engine until > ALTER TABLE ... ENABLE KEYS was run on the table. > (Bug#20357: http://bugs.mysql.com/20357) > * A number of dependency issues in the RPM bench and test > packages caused installation of these packages to fail. > (Bug#20078: http://bugs.mysql.com/20078) > * The MD5() and SHA() functions treat their arguments as > case-sensitive strings. But when they are compared, their > arguments were compared as case-insensitive strings, which > leads to two function calls with different arguments (and thus > different results) compared as being identical. This can lead > to a wrong decision made in the range optimizer and thus to an > incorrect result set. (Bug#15351: http://bugs.mysql.com/15351) > * InnoDB unlocked its data directory before committing a > transaction, potentially resulting in non-recoverable tables > if a server crash occurred before the commit. > (Bug#19727: http://bugs.mysql.com/19727) > * Multiple-table DELETE statements containing a subquery that > selected from one of the tables being modified caused a server > crash. (Bug#19225: http://bugs.mysql.com/19225) > * The ARCHIVE storage engine does not support TRUNCATE TABLE, > but the server was not returning an appropriate error when > truncation of an ARCHIVE table was attempted. > (Bug#15558: http://bugs.mysql.com/15558) > * An update that used a join of a table to itself and modified > the table on both sides of the join reported the table as > crashed. (Bug#18036: http://bugs.mysql.com/18036) > * The fill_help_tables.sql file did not load properly if the > ANSI_QUOTES SQL mode was enabled. > (Bug#20542: http://bugs.mysql.com/20542) > * The fill_help_tables.sql file did not contain a SET NAMES > 'utf8' statement to indicate its encoding. This caused > problems for some settings of the MySQL character set such as > big5. (Bug#20551: http://bugs.mysql.com/20551) > * The MySQL server startup script /etc/init.d/mysql (created > from mysql.server) is now marked to ensure that the system > services ypbind, nscd, ldap, and NTP are started first (if > these are configured on the machine). > (Bug#18810: http://bugs.mysql.com/18810) > * For a reference to a non-existent index in FORCE INDEX, the > error message referred to a column, not an index. > (Bug#17873: http://bugs.mysql.com/17873) > * In a multiple-row INSERT statement, LAST_INSERT_ID() should > return the same value for each row. However, in some cases, > the value could change if the table being inserted into had > its own AUTO_INCREMENT column. > (Bug#6880: http://bugs.mysql.com/6880) > * Invalid escape sequences in option files caused MySQL programs > that read them to abort. > (Bug#15328: http://bugs.mysql.com/15328) > * Binary log lacked character set information for table name > when dropping temporary tables. > (Bug#14157: http://bugs.mysql.com/14157) > * InnoDB did not increment the handler_read_prev counter. > (Bug#19542: http://bugs.mysql.com/19542) > * Slave SQL thread cleanup was not handled properly on Mac OS X > when a statement was killed, resulting in a slave crash. > (Bug#16900: http://bugs.mysql.com/16900) > * mysqldump did not respect the order of tables named with the > --tables option. (Bug#18536: http://bugs.mysql.com/18536) > * The server no longer uses a signal handler for signal 0 > because it could cause a crash on some platforms. > (Bug#15869: http://bugs.mysql.com/15869) > * LOAD_FILE() returned an error if the file did not exist, > rather than NULL as it should according to the manual. > (Bug#10418: http://bugs.mysql.com/10418) > * Use of uninitialized user variables in a subquery in the FROM > clause results in bad entries in the binary log. > (Bug#19136: http://bugs.mysql.com/19136) > * IS_USED_LOCK() could return an incorrect connection > identifier. (Bug#16501: http://bugs.mysql.com/16501) > * Concurrent reading and writing of privilege structures could > crash the server. (Bug#16372: http://bugs.mysql.com/16372) > * A statement containing GROUP BY and HAVING clauses could > return incorrect results when the HAVING clause contained > logic that returned FALSE for every row. > (Bug#14927: http://bugs.mysql.com/14927) > * MONTHNAME(STR_TO_DATE(NULL, '%m')) could cause a server crash. > (Bug#18501: http://bugs.mysql.com/18501) > * The ref optimizer could choose the ref_or_null access method > in cases where it was not applicable. This could cause > inconsistent EXPLAIN or SELECT results for a given statement. > (Bug#16798: http://bugs.mysql.com/16798) > * ANALYZE TABLE for TEMPORARY tables had no effect. > (Bug#15225: http://bugs.mysql.com/15225) > * When myisamchk needed to rebuild a table, AUTO_INCREMENT > information was lost. (Bug#10405: http://bugs.mysql.com/10405) > * No error message was being issued for storage engines that do > not support ALTER TABLE. Now an ER_NOT_SUPPORTED_YET error > occurs. (Bug#7643: http://bugs.mysql.com/7643) > * The binary log would create an incorrect DROP query when > creating temporary tables during replication. > (Bug#17263: http://bugs.mysql.com/17263) > > > Enjoy! > Joerg >
Is there still development going on of mysql 4? -- John Meyer Programmer, Database author "Here's something to think about: How come you never see a headline titled "Psychic Wins Lottery""---Jay Leno -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
