| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | May 7 2007 7:49pm |
| Subject: | svn commit - mysqldoc@docsrva: r6366 - in trunk: . refman-5.0 | ||
| View as plain text | |||
Author: paul Date: 2007-05-07 19:49:49 +0200 (Mon, 07 May 2007) New Revision: 6366 Log: r24649@polar: paul | 2007-05-07 12:48:39 -0500 Add 5.0.41 CS release notes. Modified: trunk/refman-5.0/releasenotes-cs-5.0.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:24647 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:20174 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:17229 + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:24649 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:20174 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:17229 Modified: trunk/refman-5.0/releasenotes-cs-5.0.xml =================================================================== --- trunk/refman-5.0/releasenotes-cs-5.0.xml 2007-05-07 16:41:44 UTC (rev 6365) +++ trunk/refman-5.0/releasenotes-cs-5.0.xml 2007-05-07 17:49:49 UTC (rev 6366) Changed blocks: 1, Lines Added: 1642, Lines Deleted: 0; 56852 bytes @@ -25,6 +25,1648 @@ to earlier versions, see <xref linkend="news"/>. </para> + <section id="releasenotes-cs-5-0-41"> + + <title>Release Notes for MySQL Community Server 5.0.41 (01 May 2007)</title> + + <para role="release-level"> + This is a bugfix release for the current production release + family. It replaces MySQL 5.0.37. + </para> + + <para> + Functionality added or changed: + </para> + + <itemizedlist> + +<!-- From 5.0.40 (begin) --> + + <listitem> + <para> + If you use SSL for a client connection, you can tell the + client not to authenticate the server certificate by + specifying neither <option>--ssl-ca</option> nor + <option>--ssl-capath</option>. The server still verifies the + client according to any applicable requirements established + via <literal>GRANT</literal> statements for the client, and it + still uses any + <option>--ssl-ca</option>/<option>--ssl-capath</option> values + that were passed to server at startup time. (Bug #25309) + </para> + </listitem> + + <listitem> + <para> + Prefix lengths for columns in <literal>SPATIAL</literal> + indexes are no longer displayed in <literal>SHOW CREATE + TABLE</literal> output. <command>mysqldump</command> uses that + statement, so if a table with <literal>SPATIAL</literal> + indexes containing prefixed columns is dumped and reloaded, + the index is created with no prefixes. (The full column width + of each column is indexed.) (Bug #26794) + </para> + </listitem> + + <listitem> + <para> + The output of <command>mysql <option>--xml</option></command> + and <command>mysqldump <option>--xml</option></command> now + includes a valid XML namespace. (Bug #25946) + </para> + </listitem> + + <listitem> + <para> + The <command>mysql_create_system_tables</command> script was + removed because <command>mysql_install_db</command> no longer + uses it in MySQL ¤t-series;. + </para> + </listitem> + + <listitem> + <para> + The syntax for index hints has been extended to enable + explicit specification that the hint applies only to join + processing. See <xref linkend="index-hints"/>. (Bug #21174) + </para> + </listitem> + + <listitem> + <para> + Binary distributions for some platforms did not include shared + libraries; now shared libraries are shipped for all platforms + except AIX 5.2 64-bit. (Bug #13450, Bug #16520, Bug #26767) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: It is now possible to restore + selected databases or tables using + <command>ndb_restore</command>. (Bug #26899) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Several options have been + added for use with <command>ndb_restore + <option>--print_data</option></command> to facilitate the + creation of data dump files. (Bug #26900) + </para> + </listitem> + +<!-- From 5.0.40 (end) --> + +<!-- From 5.0.38 (begin) --> + + <listitem> + <para> + To satisfy different user requirements, we provide several + servers. <command>mysqld</command> is an optimized server that + is a smaller, faster binary. Each package now also includes + <command>mysqld-debug</command>, which is compiled with + debugging support but is otherwise configured identically to + the non-debug server. + </para> + </listitem> + + <listitem> + <para> + Added the <option>--secure-file-priv</option> option for + <command>mysql-test-run.pl</command>, which limits the effect + of the <literal>load_file</literal> command for + <command>mysqltest</command> and for the <literal>LOAD + DATA</literal> and <literal>SELECT ... INTO OUTFILE</literal> + statements to work with files in a given directory. (Bug + #18628) + </para> + </listitem> + + <listitem> + <para> + Added the <literal>hostname</literal> system variable, which + the server sets at startup to the server hostname. + </para> + </listitem> + + <listitem> + <para> + The server now includes a timestamp in error messages that are + logged as a result of unhandled signals (such as + <literal>mysqld got signal 11</literal> messages). (Bug + #24878) + </para> + </listitem> + +<!-- From 5.0.38 (end) --> + + </itemizedlist> + + <para> + Bugs fixed: + </para> + + <itemizedlist> + +<!-- From 5.0.40 (begin) --> + + <listitem> + <para> + The patches for Bug #19370 and Bug #21789 were reverted. + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: <literal>NDB</literal> tables + having <literal>MEDIUMINT AUTO_INCREMENT</literal> columns + were not restored correctly by <command>ndb_restore</command>, + causing spurious duplicate key errors. This issue did not + affect <literal>TINYINT</literal>, <literal>INT</literal>, or + <literal>BIGINT</literal> columns with + <literal>AUTO_INCREMENT</literal>. (Bug #27775) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: <literal>NDB</literal> tables + with indexes whose names contained space characters were not + restored correctly by <command>ndb_restore</command> (the + index names were truncated). (Bug #27758) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Some queries that updated + multiple tables were not backed up correctly. (Bug #27748) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Joins on multiple tables + containing <literal>BLOB</literal> columns could cause data + nodes run out of memory, and to crash with the error + <errortext>NdbObjectIdMap::expand unable to + expand</errortext>. (Bug #26176) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal> (APIs): Using + <literal>NdbBlob::writeData()</literal> to write data in the + middle of an existing blob value (that is, updating the value) + could overwrite some data past the end of the data to be + changed. (Bug #27018) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Under certain rare + circumstances, <literal>DROP TABLE</literal> or + <literal>TRUNCATE</literal> of an <literal>NDB</literal> table + could cause a node failure or forced cluster shutdown. (Bug + #27581) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Memory usage of a + <command>mysqld</command> process grew even while idle. (Bug + #27560) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: In some cases, <literal>AFTER + UPDATE</literal> and <literal>AFTER DELETE</literal> triggers + on <literal>NDB</literal> tables that referenced subject table + did not see the results of operation which caused invocation + of the trigger, but rather saw the row as it was prior to the + update or delete operation. + </para> + + <para> + This was most noticeable when an update operation used a + subquery to obtain the rows to be updated. An example would be + <literal>UPDATE tbl1 SET col2 = val1 WHERE tbl1.col1 IN + (SELECT col3 FROM tbl2 WHERE c4 = val2)</literal> where there + was an <literal>AFTER UPDATE</literal> trigger on table + <literal>tbl1</literal>. In such cases, the trigger would fail + to execute. + </para> + + <para> + The problem occurred because the actual update or delete + operations were deferred to be able to perform them later as + one batch. The fix for this bug solves the problem by + disabling this optimization for a given update or delete if + the table has an <literal>AFTER</literal> trigger defined for + this operation. (Bug #26242) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Condition pushdown did not + work with prepared statements. (Bug #26225) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: When trying to create tables + on an SQL node not connected to the cluster, a misleading + error message <errortext>Table + '<replaceable>tbl_name</replaceable>' already + exists</errortext> was generated. The error now generated is + <errortext>Could not connect to storage engine</errortext>. + (Bug #18676) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Error messages displayed when + running in single user mode were inconsistent. (Bug #27021) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: On Solaris, the value of an + <literal>NDB</literal> table column declared as + <literal>BIT(33)</literal> was always displayed as + <literal>0</literal>. (Bug #26986) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: The output from + <command>ndb_restore <option>--print_data</option></command> + was incorrect for a backup made of a database containing + tables with <literal>TINYINT</literal> or + <literal>SMALLINT</literal> columns. (Bug #26740) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: After entering single user + mode it was not possible to alter non-<literal>NDB</literal> + tables on any SQL nodes other than the one having sole access + to the cluster. (Bug #25275) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: The failure of a data node + while restarting could cause other data nodes to hang or + crash. (Bug #27003) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: The management client command + <literal><replaceable>node_id</replaceable> STATUS</literal> + displayed the message <literal>Node + <replaceable>node_id</replaceable>: not connected</literal> + when <replaceable>node_id</replaceable> was not the node ID of + a data node. (Bug #21715) + </para> + + <note> + <para> + The <literal>ALL STATUS</literal> command in the cluster + management client still displays status information for data + nodes only. This is by design. See + <xref linkend="mysql-cluster-mgm-client-commands"/>, for + more information. + </para> + </note> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: It was not possible to set + <literal>LockPagesInMainMemory</literal> equal to + <literal>0</literal>. (Bug #27291) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: A race condition could + sometimes occur if the node acting as master failed while node + IDs were still being allocated during startup. (Bug #27286) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: When a data node was taking + over as the master node, a race condition could sometimes + occur as the node was assuming responsibility for handling of + global checkpoints. (Bug #27283) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: <command>mysqld</command> + processes would sometimes crash under high load. (Bug #26825) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Some values of + <literal>MaxNoOfTables</literal> caused the error + <errortext>Job buffer congestion</errortext> to occur. (Bug + #19378) + </para> + </listitem> + + <listitem> + <para> + Some equi-joins containing a <literal>WHERE</literal> clause + that included a <literal>NOT IN</literal> subquery caused a + server crash. (Bug #27870) + </para> + </listitem> + + <listitem> + <para> + Windows binaries contained no debug symbol file. Now + <filename>.map</filename> and <literal>.pdb</literal> files + are included in 32-bit builds for + <command>mysqld-nt.exe</command>, + <command>mysqld-debug.exe</command>, and + <command>mysqlmanager.exe</command>. (Bug #26893) + </para> + </listitem> + + <listitem> + <para> + The test for the + <literal>MYSQL_OPT_SSL_VERIFY_SERVER_CERT</literal> option for + <literal>mysql_options()</literal> was performed incorrectly. + Also changed as a result of this bugfix: The + <literal>arg</literal> option for the + <literal>mysql_options()</literal> C API function was changed + from <literal>char *</literal> to <literal>void *</literal>. + (Bug #24121) + </para> + </listitem> + + <listitem> + <para> + The range optimizer could consume a combinatorial amount of + memory for certain classes of <literal>WHERE</literal> + clauses. (Bug #26624) + </para> + </listitem> + + <listitem> + <para> + Conversion of <literal>DATETIME</literal> values in numeric + contexts sometimes did not produce a double + (<literal>YYYYMMDDHHMMSS.uuuuuu</literal>) value. (Bug #16546) + </para> + </listitem> + + <listitem> + <para> + Passing nested row expressions with different structures to an + <literal>IN</literal> predicate caused a server crash. (Bug + #27484) + </para> + </listitem> + + <listitem> + <para> + <literal>SELECT DISTINCT</literal> could return incorrect + results if the select list contained duplicated columns. (Bug + #27659) + </para> + </listitem> + + <listitem> + <para> + A subquery could get incorrect values for references to outer + query columns when it contained aggregate functions that were + aggregated in outer context. (Bug #27321) + </para> + </listitem> + + <listitem> + <para> + In some cases, the optimizer preferred a range or full index + scan access method over lookup access methods when the latter + were much cheaper. (Bug #19372) + </para> + </listitem> + + <listitem> + <para> + Duplicates were not properly identified among (potentially) + long strings used as arguments for + <literal>GROUP_CONCAT(DISTINCT)</literal>. (Bug #26815) + </para> + </listitem> + + <listitem> + <para> + For <literal>InnoDB</literal>, fixed consistent-read behavior + of the first read statement, if the read was served from the + query cache, for the <literal>READ COMMITTED</literal> + isolation level. (Bug #21409) + </para> + </listitem> + + <listitem> + <para> + The <filename>decimal.h</filename> header file was incorrectly + omitted from binary distributions. (Bug #27456) + </para> + </listitem> + + <listitem> + <para> + Duplicate members in <literal>SET</literal> definitions were + not detected. Now they result in a warning; if strict SQL mode + is enabled, an error occurs instead. (Bug #27069) + </para> + </listitem> + + <listitem> + <para> + For <literal>INSERT INTO ... SELECT</literal> where index + searches used column prefixes, insert errors could occur when + key value type conversion was done. (Bug #26207) + </para> + </listitem> + + <listitem> + <para> + For <literal>SHOW ENGINE INNODB STATUS</literal>, the + <literal>LATEST DEADLOCK INFORMATION</literal> was not always + cleared properly. (Bug #25494) + </para> + </listitem> + + <listitem> + <para> + <literal>mysqldump</literal> could crash or exhibit incorrect + behavior when some options were given very long values, such + as <option>--fields-terminated-by="<replaceable>some very long + string</replaceable>"</option>. The code has been cleaned up + to remove a number of fixed-sized buffers and to be more + careful about error conditions in memory allocation. (Bug + #26346) + </para> + </listitem> + + <listitem> + <para> + Setting a column to <literal>NOT NULL</literal> with an + <literal>ON DELETE SET NULL</literal> clause foreign key + crashes the server. (Bug #25927) + </para> + </listitem> + + <listitem> + <para> + The values displayed for the + <literal>Innodb_row_lock_time</literal>, + <literal>Innodb_row_lock_time_avg</literal>, and + <literal>Innodb_row_lock_time_max</literal> status variables + were incorrect. (Bug #23666) + </para> + </listitem> + + <listitem> + <para> + <literal>COUNT(<replaceable>decimal_expr</replaceable>)</literal> + sometimes generated a spurious truncation warning. (Bug + #21976) + </para> + </listitem> + + <listitem> + <para> + With <literal>NO_AUTO_VALUE_ON_ZERO</literal> SQL mode + enabled, <literal>LOAD DATA</literal> operations could assign + incorrect <literal>AUTO_INCREMENT</literal> values. (Bug + #27586) + </para> + </listitem> + + <listitem> + <para> + Incorrect results could be returned for some queries that + contained a select list expression with <literal>IN</literal> + or <literal>BETWEEN</literal> together with an <literal>ORDER + BY</literal> or <literal>GROUP BY</literal> on the same + expression using <literal>NOT IN</literal> or <literal>NOT + BETWEEN</literal>. (Bug #27532) + </para> + </listitem> + + <listitem> + <para> + Queries containing subqueries with <literal>COUNT(*)</literal> + aggregated in an outer context returned incorrect results. + This happened only if the subquery did not contain any + references to outer columns. (Bug #27257) + </para> + </listitem> + + <listitem> + <para> + Use of an aggregate function from an outer context as an + argument to <literal>GROUP_CONCAT()</literal> caused a server + crash. (Bug #27229) + </para> + </listitem> + + <listitem> + <para> + <literal>REPAIR TABLE ... USE_FRM</literal> with an + <literal>ARCHIVE</literal> table deleted all records from the + table. (Bug #26138) + </para> + </listitem> + + <listitem> + <para> + On Windows, debug builds of <command>mysqld</command> could + fail with heap assertions. (Bug #25765) + </para> + </listitem> + + <listitem> + <para> + On Windows, debug builds of <command>mysqlbinlog</command> + could fail with a memory error. (Bug #23736) + </para> + </listitem> + + <listitem> + <para> + String truncation upon insertion into an integer or year + column did not generate a warning (or an error in strict + mode). (Bug #26359, Bug #27176) + </para> + </listitem> + + <listitem> + <para> + In out-of-memory conditions, the server might crash or + otherwise not report an error to the Windows event log. (Bug + #27490) + </para> + </listitem> + + <listitem> + <para> + The temporary file-creation code was cleaned up on Windows to + improve server stability. (Bug #26233) + </para> + </listitem> + + <listitem> + <para> + Out-of-memory errors for slave I/O threads were not reported. + Now they are written to the error log. (Bug #26844) + </para> + </listitem> + + <listitem> + <para> + <command>mysqldump</command> crashed for + <literal>MERGE</literal> tables if the + <option>--complete-insert</option> (<option>-c</option>) + option was given. (Bug #25993) + </para> + </listitem> + + <listitem> + <para> + In certain situations, <literal>MATCH ... AGAINST</literal> + returned false hits for <literal>NULL</literal> values + produced by <literal>LEFT JOIN</literal> when no full-text + index was available. (Bug #25729) + </para> + </listitem> + + <listitem> + <para> + <literal>OPTIMIZE TABLE</literal> might fail on Windows when + it attempts to rename a temporary file to the original name if + the original file had been opened, resulting in loss of the + <filename>.MYD</filename> file. (Bug #25521) + </para> + </listitem> + + <listitem> + <para> + <literal>GRANT</literal> statements were not replicated if the + server was started with the + <option>--replicate-ignore-table</option> or + <option>--replicate-wild-ignore-table</option> option. (Bug + #25482) + </para> + </listitem> + + <listitem> + <para> + A problem in handling of aggregate functions in subqueries + caused predicates containing aggregate functions to be ignored + during query execution. (Bug #24484) + </para> + </listitem> + + <listitem> + <para> + Improved out-of-memory detection when sending logs from a + master server to slaves, and log a message when allocation + fails. (Bug #26837) + </para> + </listitem> + + <listitem> + <para> + <literal>MBROverlaps()</literal> returned incorrect values in + some cases. (Bug #24563) + </para> + </listitem> + + <listitem> + <para> + <literal>SHOW CREATE VIEW</literal> qualified references to + stored functions in the view definition with the function's + database name, even when the database was the default + database. This affected <command>mysqldump</command> (which + uses <literal>SHOW CREATE VIEW</literal> to dump views) + because the resulting dump file could not be used to reload + the database into a different database. <literal>SHOW CREATE + VIEW</literal> now suppresses the database name for references + to functions in the default database. (Bug #23491) + </para> + </listitem> + + <listitem> + <para> + With <literal>innodb_file_per_table</literal> enabled, + attempting to rename an <literal>InnoDB</literal> table to a + non-existent database caused the server to exit. (Bug #27381) + </para> + </listitem> + + <listitem> + <para> + <command>mysql_install_db</command> could terminate with an + error after failing to determine that a system table already + existed. (Bug #27022) + </para> + </listitem> + + <listitem> + <para> + For <literal>InnoDB</literal> tables having a clustered index + that began with a <literal>CHAR</literal> or + <literal>VARCHAR</literal> column, deleting a record and then + inserting another before the deleted record was purged could + result in table corruption. (Bug #26835) + </para> + </listitem> + + <listitem> + <para> + Selecting the result of <literal>AVG()</literal> within a + <literal>UNION</literal> could produce incorrect values. (Bug + #24791) + </para> + </listitem> + + <listitem> + <para> + An <literal>INTO OUTFILE</literal> clause is allowed only for + the final <literal>SELECT</literal> of a + <literal>UNION</literal>, but this restriction was not being + enforced correctly. (Bug #23345) + </para> + </listitem> + + <listitem> + <para> + Duplicate entries were not assessed correctly in a + <literal>MEMORY</literal> table with a + <literal>BTREE</literal> primary key on a + <literal>utf8</literal> <literal>ENUM</literal> column. (Bug + #24985) + </para> + </listitem> + + <listitem> + <para> + For <literal>MyISAM</literal> tables, + <literal>COUNT(*)</literal> could return an incorrect value if + the <literal>WHERE</literal> clause compared an indexed + <literal>TEXT</literal> column to the empty string + (<literal>''</literal>). This happened if the column contained + empty strings and also strings starting with control + characters such as tab or newline. (Bug #26231) + </para> + </listitem> + + <listitem> + <para> + For <literal>DELETE FROM <literal>tbl_name</literal> ORDER BY + <replaceable>col_name</replaceable></literal> (with no + <literal>WHERE</literal> or <literal>LIMIT</literal> clause), + the server did not check whether + <replaceable>col_name</replaceable> was a valid column in the + table. (Bug #26186) + </para> + </listitem> + + <listitem> + <para> + <literal>ALTER VIEW</literal> requires the <literal>CREATE + VIEW</literal> and <literal>DROP</literal> privileges for the + view. However, if the view was created by another user, the + server erroneously required the <literal>SUPER</literal> + privilege. (Bug #26813) + </para> + </listitem> + + <listitem> + <para> + In a view, a column that was defined using a + <literal>GEOMETRY</literal> function was treated as having the + <literal>LONGBLOB</literal> data type rather than the + <literal>GEOMETRY</literal> type. (Bug #27300) + </para> + </listitem> + + <listitem> + <para> + With the <literal>NO_AUTO_VALUE_ON_ZERO</literal> SQL mode + enabled, <literal>LAST_INSERT_ID()</literal> could return 0 + after <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal>. + Additionally, the next rows inserted (by the same + <literal>INSERT</literal>, or the following + <literal>INSERT</literal> with or without <literal>ON + DUPLICATE KEY UPDATE</literal>), would insert 0 for the + auto-generated value if the value for the + <literal>AUTO_INCREMENT</literal> column was + <literal>NULL</literal> or missing. (Bug #23233) + </para> + </listitem> + + <listitem> + <para> + For a stored procedure containing a <literal>SELECT</literal> + statement that used a complicated join with an + <literal>ON</literal> expression, the expression could be + ignored during re-execution of the procedure, yielding an + incorrect result. (Bug #20492) + </para> + </listitem> + + <listitem> + <para> + When RAND() was called multiple times inside a stored + procedure, the server did not write the correct random seed + values to the binary log, resulting in incorrect replication. + (Bug #25543) + </para> + </listitem> + + <listitem> + <para> + <literal>SOUNDEX()</literal> returned an invalid string for + international characters in multi-byte character sets. (Bug + #22638) + </para> + </listitem> + + <listitem> + <para> + Row equalities in <literal>WHERE</literal> clauses could cause + memory corruption. (Bug #27154) + </para> + </listitem> + + <listitem> + <para> + <literal>GROUP BY</literal> on a <literal>ucs2</literal> + column caused a server crash when there was at least one empty + string in the column. (Bug #27079) + </para> + </listitem> + + <listitem> + <para> + Evaluation of an <literal>IN()</literal> predicate containing + a decimal-valued argument caused a server crash. (Bug #27362) + </para> + </listitem> + + <listitem> + <para> + Storing <literal>NULL</literal> values in spatial fields + caused excessive memory allocation and crashes on some + systems. (Bug #27164) + </para> + </listitem> + + <listitem> + <para> + <literal>mysql_stmt_fetch()</literal> did an invalid memory + deallocation when used with the embedded server. (Bug #25492) + </para> + </listitem> + + <listitem> + <para> + In a <literal>MEMORY</literal> table, using a + <literal>BTREE</literal> index to scan for updatable rows + could lead to an infinite loop. (Bug #26996) + </para> + </listitem> + + <listitem> + <para> + The range optimizer could cause the server to run out of + memory. (Bug #26625) + </para> + </listitem> + + <listitem> + <para> + The parser accepted illegal code in SQL exception handlers, + leading to a crash at runtime when executing the code. (Bug + #26503) + </para> + </listitem> + + <listitem> + <para> + Difficult repair or optimization operations could cause an + assertion failure, resulting in a server crash. (Bug #25289) + </para> + </listitem> + + <listitem> + <para> + Increasing the width of a <literal>DECIMAL</literal> column + could cause column values to be changed. (Bug #24558) + </para> + </listitem> + + <listitem> + <para> + Replication between master and slave would infinitely retry + binary log transmission where the + <option>max_allowed_packet</option> on the master was larger + than that on the slave if the size of the transfer was between + these two values. (Bug #23775) + </para> + </listitem> + + <listitem> + <para> + Invalid optimization of pushdown conditions for queries where + an outer join was guaranteed to read only one row from the + outer table led to results with too few rows. (Bug #26963) + </para> + </listitem> + + <listitem> + <para> + For <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal> + statements on tables containing + <literal>AUTO_INCREMENT</literal> columns, + <literal>LAST_INSERT_ID()</literal> was reset to 0 if no rows + were successfully inserted or changed. <quote>Not + changed</quote> includes the case where a row was updated to + its current values, but in that case, + <literal>LAST_INSERT_ID()</literal> should not be reset to 0. + Now <literal>LAST_INSERT_ID()</literal> is reset to 0 only if + no rows were successfully inserted or touched, whether or not + touched rows were changed. (Bug #27033) + </para> + + <para> + This bug was introduced by the fix for Bug #19978. + </para> + </listitem> + + <listitem> + <para> + For an <literal>INSERT</literal> statement that should fail + due to a column with no default value not being assigned a + value, the statement succeeded with no error if the column was + assigned a value in an <literal>ON DUPLICATE KEY + UPDATE</literal> clause, even if that clause was not used. + (Bug #26261) + </para> + </listitem> + + <listitem> + <para> + A result set column formed by concatention of string literals + was incomplete when the column was produced by a subquery in + the <literal>FROM</literal> clause. (Bug #26738) + </para> + </listitem> + + <listitem> + <para> + When using the result of <literal>SEC_TO_TIME()</literal> for + time value greater than 24 hours in an <literal>ORDER + BY</literal> clause, either directly or through a column + alias, the rows were sorted incorrectly as strings. (Bug + #26672) + </para> + </listitem> + + <listitem> + <para> + If the server was started with + <option>--skip-grant-tables</option>, Selecting from + <literal>INFORMATION_SCHEMA</literal> tables causes a server + crash. (Bug #26285) + </para> + </listitem> + +<!-- From 5.0.40 (end) --> + +<!-- From 5.0.38 (begin) --> + + <listitem> + <para> + <emphasis role="bold">Incompatible change</emphasis>: + <literal>INSERT DELAYED</literal> statements are not supported + for <literal>MERGE</literal> tables, but the + <literal>MERGE</literal> storage engine was not rejecting such + statements, resulting in table corruption. Applications + previously using <literal>INSERT DELAYED</literal> into + <literal>MERGE</literal> table will break when upgrading to + versions with this fix. To avoid the problem, remove + <literal>DELAYED</literal> from such statements. (Bug #26464) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: An invalid pointer was + returned following a <literal>FSCLOSECONF</literal> signal + when accessing the REDO logs during a node restart or system + restart. (Bug #26515) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: An inadvertent use of + unaligned data caused <command>ndb_restore</command> to fail + on some 64-bit platforms, including Sparc and Itanium-2. (Bug + #26739) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: An infinite loop in an + internal logging function could cause trace logs to fill up + with <errortext>Unknown Signal type</errortext> error messages + and thus grow to unreasonable sizes. (Bug #26720) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: The failure of a data node + when restarting it with <option>--initial</option> could lead + to failures of subsequent data node restarts. (Bug #26481) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Takeover for local + checkpointing due to multiple failures of master nodes was + sometimes incorrect handled. (Bug #26457) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: The + <literal>LockPagesInMemory</literal> parameter was not read + until after distributed communication had already started + between cluster nodes. When the value of this parameter was + <literal>1</literal>, this could sometimes result in data node + failure due to missed heartbeats. (Bug #26454) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: Under some circumstances, + following the restart of a management, all cluster data nodes + would connect to it normally, but some of them subsequently + failed to log any events to the management node. (Bug #26293) + </para> + </listitem> + + <listitem> + <para> + <literal>NDB Cluster</literal>: An error was produced when + <literal>SHOW TABLE STATUS</literal> was used on an + <literal>NDB</literal> table that had no + <literal>AUTO_INCREMENT</literal> column. (Bug #21033) + </para> + </listitem> + + <listitem> + <para> + <literal>SELECT ... INTO OUTFILE</literal> with a long + <literal>FIELDS ENCLOSED BY</literal> value could crash the + server. (Bug #27231) + </para> + </listitem> + + <listitem> + <para> + <literal>DOUBLE</literal> values such as + <literal>20070202191048.000000</literal> were being treated as + illegal arguments by <literal>WEEK()</literal>. (Bug #23616) + </para> + </listitem> + + <listitem> + <para> + <literal>AFTER UPDATE</literal> triggers were not activated by + the update part of <literal>INSERT ... ON DUPLICATE KEY + UPDATE</literal> statements. (Bug #27006, Bug #27210) + </para> + + <para> + This bug was introduced by the fix for Bug #19978. + </para> + </listitem> + + <listitem> + <para> + For <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal> + statements where some <literal>AUTO_INCREMENT</literal> values + were generated automatically for inserts and some rows were + updated, one auto-generated value was lost per updated row, + leading to faster exhaustion of the range of the + <literal>AUTO_INCREMENT</literal> column. (Bug #24432) + </para> + + <para> + Because the original problem can affect replication (different + values on master and slave), it is recommended that the master + and its slaves be upgraded to the current version. + </para> + </listitem> + + <listitem> + <para> + <literal>IN ((<replaceable>subquery</replaceable>))</literal>, + <literal>IN + (((<replaceable>subquery</replaceable>)))</literal>, and so + forth, are equivalent to <literal>IN + (<replaceable>subquery</replaceable>)</literal>, which is + always interpreted as a table subquery (so that it is allowed + to return more than one row). MySQL was treating the + <quote>over-parenthesized</quote> subquery as a single-row + subquery and rejecting it if it returned more than one row. + This bug primarily affected automatically generated code (such + as queries generated by Hibernate), because humans rarely + write the over-parenthesized forms. (Bug #21904) + </para> + </listitem> + + <listitem> + <para> + For <literal>MERGE</literal> tables defined on underlying + tables that contained a short <literal>VARCHAR</literal> + column (shorter than four characters), using <literal>ALTER + TABLE</literal> on at least one but not all of the underlying + tables caused the table definitions to be considered different + from that of the <literal>MERGE</literal> table, even if the + <literal>ALTER TABLE</literal> did not change the definition. + (Bug #26881) + </para> + </listitem> + + <listitem> + <para> + If a thread previously serviced a connection that was killed, + excessive memory and CPU use by the thread occurred if it + later serviced a connection that had to wait for a table lock. + (Bug #25966) + </para> + </listitem> + + <listitem> + <para> + <literal>CURDATE()</literal> is less than + <literal>NOW()</literal>, either when comparing + <literal>CURDATE()</literal> directly (<literal>CURDATE() < + NOW()</literal> is true) or when casting + <literal>CURDATE()</literal> to <literal>DATE</literal> + (<literal>CAST(CURDATE() AS DATE) < NOW()</literal> is + true). However, storing <literal>CURDATE()</literal> in a + <literal>DATE</literal> column and comparing + <literal><replaceable>col_name</replaceable> < + NOW()</literal> incorrectly yielded false. This is fixed by + comparing a <literal>DATE</literal> column as + <literal>DATETIME</literal> for comparisons to a + <literal>DATETIME</literal> constant. (Bug #21103) + </para> + </listitem> + + <listitem> + <para> + A view on a join is insertable for <literal>INSERT</literal> + statements that store values into only one table of the join. + However, inserts were being rejected if the inserted-into + table was used in a self-join because MySQL incorrectly was + considering the insert to modify multiple tables of the view. + (Bug #25122) + </para> + </listitem> + + <listitem> + <para> + Expressions involving <literal>SUM()</literal>, when used in + an <literal>ORDER BY</literal> clause, could lead to + out-of-order results. (Bug #25376) + </para> + </listitem> + + <listitem> + <para> + <literal>LOAD DATA INFILE</literal> sent an okay to the client + before writing the binary log and committing the changes to + the table had finished, thus violating ACID requirements. (Bug + #26050) + </para> + </listitem> + + <listitem> + <para> + Views that used a scalar correlated subquery returned + incorrect results. (Bug #26560) + </para> + </listitem> + + <listitem> + <para> + IF(<replaceable>expr</replaceable>, + <replaceable>unsigned_expr</replaceable>, + <replaceable>unsigned_expr</replaceable>) was evaluated to a + signed result, not unsigned. This has been corrected. The fix + also affects constructs of the form <literal>IS [NOT] + {TRUE|FALSE}</literal>, which were transformed internally into + <literal>IF()</literal> expressions that evaluated to a signed + result. (Bug #24532) + </para> + + <para> + For existing views that were defined using <literal>IS [NOT] + {TRUE|FALSE}</literal> constructs, there is a related + implication. The definitions of such views were stored using + the <literal>IF()</literal> expression, not the original + construct. This is manifest in that <literal>SHOW CREATE + VIEW</literal> shows the transformed <literal>IF()</literal> + expression, not the original one. Existing views will evaluate + correctly after the fix, but if you want <literal>SHOW CREATE + VIEW</literal> to display the original construct, you must + drop the view and re-create it using its original definition. + New views will retain the construct in their definition. + </para> + </listitem> + + <listitem> + <para> + <literal>BENCHMARK()</literal> did not work correctly for + expressions that produced a <literal>DECIMAL</literal> result. + (Bug #26093) + </para> + </listitem> + + <listitem> + <para> + For some values of the position argument, the + <literal>INSERT()</literal> function could insert a NUL byte + into the result. (Bug #26281) + </para> + </listitem> + + <listitem> + <para> + Inserting <literal>utf8</literal> data into a + <literal>TEXT</literal> column that used a single-byte + character set could result in spurious warnings about + truncated data. (Bug #25815) + </para> + </listitem> + + <listitem> + <para> + <literal>EXPLAIN EXTENDED</literal> did not show + <literal>WHERE</literal> conditions that were optimized away. + (Bug #22331) + </para> + </listitem> + + <listitem> + <para> + <literal>INSERT DELAYED</literal> statements inserted + incorrect values into <literal>BIT</literal> columns. (Bug + #26238) + </para> + </listitem> + + <listitem> + <para> + For <literal><replaceable>expr</replaceable> + IN(<replaceable>value_list</replaceable>)</literal>, the + result could be incorrect if <literal>BIGINT + UNSIGNED</literal> values were used for + <replaceable>expr</replaceable> or in the value list. (Bug + #19342) + </para> + </listitem> + + <listitem> + <para> + When a <literal>TIME_FORMAT()</literal> expression was used as + a column in a <literal>GROUP BY</literal> clause, the + expression result was truncated. (Bug #20293) + </para> + </listitem> + + <listitem> + <para> + For <literal>SUBSTRING()</literal> evaluation using a + temporary table, when <literal>SUBSTRING()</literal> was used + on a LONGTEXT column, the <literal>max_length</literal> + metadata value of the result was incorrectly calculated and + set to 0. Consequently, an empty string was returned instead + of the correct result. (Bug #15757) + </para> + </listitem> + + <listitem> + <para> + Use of a <literal>GROUP BY</literal> clause that referred to a + stored function result together with <literal>WITH + ROLLUP</literal> caused incorrect results. (Bug #25373) + </para> + </listitem> + + <listitem> + <para> + Use of a subquery containing <literal>GROUP BY</literal> and + <literal>WITH ROLLUP</literal> caused a server crash. (Bug + #26830) + </para> + </listitem> + + <listitem> + <para> + Use of a subquery containing a <literal>UNION</literal> with + an invalid <literal>ORDER BY</literal> clause caused a server + crash. (Bug #26661) + </para> + </listitem> + + <listitem> + <para> + In certain cases it could happen that deleting a row corrupted + an <literal>RTREE</literal> index. This affected indexes on + spatial columns. (Bug #25673) + </para> + </listitem> + + <listitem> + <para> + SSL connections failed on Windows. (Bug #26678) + </para> + </listitem> + + <listitem> + <para> + Added support for <option>--debugger=dbx</option> for + <command>mysql-test-run.pl</command> and fixed support for + <option>--debugger=devenv</option>, + <option>--debugger=DevEnv</option>, and + <option>--debugger=<replaceable>/path/to</replaceable>/devenv</option>. + (Bug #26792) + </para> + </listitem> + + <listitem> + <para> + <literal>X() IS NULL</literal> and <literal>Y() IS + NULL</literal> comparisons failed when <literal>X()</literal> + and <literal>Y()</literal> returned <literal>NULL</literal>. + (Bug #26038) + </para> + </listitem> + + <listitem> + <para> + <literal>UNHEX() IS NULL</literal> comparisons failed when + <literal>UNHEX()</literal> returned <literal>NULL</literal>. + (Bug #26537) + </para> + </listitem> + + <listitem> + <para> + The <literal>REPEAT()</literal> function did not allow a + column name as the <replaceable>count</replaceable> parameter. + (Bug #25197) + </para> + </listitem> + + <listitem> + <para> + On 64-bit Windows, large timestamp values could be handled + incorrectly. (Bug #26536) + </para> + </listitem> + + <listitem> + <para> + In some error messages, inconsistent format specifiers were + used for the translations in different languages. + <command>comp_err</command> (the error message compiler) now + checks for mismatches. (Bug #26571) + </para> + </listitem> + + <listitem> + <para> + On Windows, the server exhibited a file-handle leak after + reaching the limit on the number of open file descriptors. + (Bug #25222) + </para> + </listitem> + + <listitem> + <para> + A reference to a non-existent column in the <literal>ORDER + BY</literal> clause of an <literal>UPDATE ... ORDER + BY</literal> statement could cause a server crash. (Bug + #25126) + </para> + </listitem> + + <listitem> + <para> + A multiple-row delayed insert with an auto increment column + could cause duplicate entries to be created on the slave in a + replication environment. (Bug #25507, Bug #26116) + </para> + </listitem> + + <listitem> + <para> + Duplicating the usage of a user variable in a stored procedure + or trigger would not be replicated correctly to the slave. + (Bug #25167) + </para> + </listitem> + + <listitem> + <para> + User defined variables used within stored procedures and + triggers are not replicated correctly when operating in + statement-based replication mode. (Bug #20141, Bug #14914) + </para> + </listitem> + + <listitem> + <para> + Loading data using <literal>LOAD DATA INFILE</literal> may not + replicate correctly (due to character set incompatibilities) + if the <literal>character_set_database</literal> variable is + set before the data is loaded. (Bug #15126) + </para> + </listitem> + + <listitem> + <para> + <literal>DROP TRIGGER</literal> statements would not be + filtered on the slave when using the + <literal>replication-wild-do-table</literal> option. (Bug + #24478) + </para> + </listitem> + + <listitem> + <para> + MySQL would not compile when configured using + <option>--without-query-cache</option>. (Bug #25075) + </para> + </listitem> + + <listitem> + <para> + When using certain server SQL modes, the + <literal>mysql.proc</literal> table was not created by + <command>mysql_install_db</command>. In addition, the creation + of this and other MySQL system tables was not checked for by + <command>mysql-test-run.pl</command>. (Bug #23669, Bug #20166) + </para> + </listitem> + + <listitem> + <para> + <literal>VIEW</literal> restrictions were applied to + <literal>SELECT</literal> statements after a <literal>CREATE + VIEW</literal> statement failed, as though the + <literal>CREATE</literal> had succeeded. (Bug #25897) + </para> + </listitem> + + <listitem> + <para> + An <literal>INSERT</literal> trigger invoking a stored routine + that inserted into a table other than the one on which the + trigger was defined would fail with a <errortext>Table '...' + doesn't exist</errortext> referring to the second table when + attempting to delete records from the first table. (Bug + #21825) + </para> + </listitem> + + <listitem> + <para> + A stored procedure that made use of cursors failed when the + procedure was invoked from a stored function. (Bug #25345) + </para> + </listitem> + + <listitem> + <para> + When nesting stored procedures within a trigger on a table, a + false dependency error was thrown when one of the nested + procedures contained a <literal>DROP TABLE</literal> + statement. (Bug #22580) + </para> + </listitem> + + <listitem> + <para> + When attempting to call a stored procedure creating a table + from a trigger on a table <literal>tbl</literal> in a database + <literal>db</literal>, the trigger failed with + <errortext>ERROR 1146 (42S02): Table 'db.tbl' doesn't + exist</errortext>. However, the actual reason that such a + trigger fails is due to the fact that <literal>CREATE + TABLE</literal> causes an implicit <literal>COMMIT</literal>, + and so a trigger cannot invoke a stored routine containing + this statement. A trigger which does so now fails with + <errortext>ERROR 1422 (HY000): Explicit or implicit commit is + not allowed in stored function or trigger</errortext>, which + makes clear the reason for the trigger's failure. (Bug #18914) + </para> + </listitem> + + <listitem> + <para> + Local variables in stored routines or triggers, when declared + as the <literal>BIT</literal> type, were interpreted as + strings. (Bug #12976) + </para> + </listitem> + + <listitem> + <para> + When a stored routine attempted to execute a statement + accessing a nonexistent table, the error was not caught by the + routine's exception handler. (Bug #8407, Bug #20713) + </para> + </listitem> + + <listitem> + <para> + <literal>NOW()</literal> returned the wrong value in + statements executed at server startup with the + <option>--init-file</option> option. (Bug #23240) + </para> + </listitem> + + <listitem> + <para> + Instance Manager did not remove the angel PID file on a clean + shutdown. (Bug #22511) + </para> + </listitem> + + <listitem> + <para> + The server could crash if two or more threads initiated query + cache resize operation at moments very close in time. (Bug + #23527) + </para> + </listitem> + + <listitem> + <para> + The conditions checked by the optimizer to allow use of + indexes in <literal>IN</literal> predicate calculations were + unnecessarily tight and were relaxed. (Bug #20420) + </para> + </listitem> + + <listitem> + <para> + Several deficiencies in resolution of column names for + <literal>INSERT ... SELECT</literal> statements were + corrected. (Bug #25831) + </para> + </listitem> + + <listitem> + <para> + Indexes on <literal>TEXT</literal> columns were ignored when + <literal>ref</literal> accesses were evaluated. (Bug #25971) + </para> + </listitem> + + <listitem> + <para> + The update columns for <literal>INSERT ... SELECT ... ON + DUPLICATE KEY UPDATE</literal> could be assigned incorrect + values if a temporary table was used to evaluate the + <literal>SELECT</literal>. (Bug #16630) + </para> + </listitem> + + <listitem> + <para> + <literal>CONNECTION</literal> is no longer treated as a + reserved word. (Bug #12204) + </para> + </listitem> + + <listitem> + <para> + A user-defined variable could be assigned an incorrect value + if a temporary table was employed in obtaining the result of + the query used to determine its value. (Bug #24010) + </para> + </listitem> + + <listitem> + <para> + Queries that used a temporary table for the outer query when + evaluating a correlated subquery could return incorrect + results. (Bug #23800) + </para> + </listitem> + + <listitem> + <para> + For index reads, the <literal>BLACKHOLE</literal> engine did + not return end-of-file (which it must because + <literal>BLACKHOLE</literal> tables contain no rows), causing + some queries to crash. (Bug #19717) + </para> + </listitem> + +<!-- From 5.0.38 (end) --> + + </itemizedlist> + + </section> + <section id="releasenotes-cs-5-0-37"> <title>Release Notes for MySQL Community Server 5.0.37 (27 February 2007)</title>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r6366 - in trunk: . refman-5.0 | paul | 7 May |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.084 sec. using MySQL 5.1.14-beta-log