| List: | Commits | « Previous MessageNext Message » | |
| From: | jon | Date: | November 18 2007 7:44pm |
| Subject: | svn commit - mysqldoc@docsrva: r8782 - trunk/dynamic-docs/changelog | ||
| View as plain text | |||
Author: jstephens Date: 2007-11-18 19:44:53 +0100 (Sun, 18 Nov 2007) New Revision: 8782 Log: Consolidated more duplicate changelog entries Modified: trunk/dynamic-docs/changelog/dupes.txt trunk/dynamic-docs/changelog/mysqld.xml Modified: trunk/dynamic-docs/changelog/dupes.txt =================================================================== --- trunk/dynamic-docs/changelog/dupes.txt 2007-11-18 14:59:57 UTC (rev 8781) +++ trunk/dynamic-docs/changelog/dupes.txt 2007-11-18 18:44:53 UTC (rev 8782) Changed blocks: 2, Lines Added: 44, Lines Deleted: 43; 991 bytes @@ -160,6 +160,7 @@ 18472x 18516x 18628x +18630x 18676x 18912x 18934x @@ -249,54 +250,54 @@ 25422x 25530x 25578x -25621 -25686 -25711 -25741 -25743 -25755 -25794 -25801 -25877 -25941 -25997 -26121 -26293 -26342 -26454 -26457 -26481 -26487 -26490 -26503 -26514 -26515 +25621x +25686x +25711x +25741x +25743x +25755x +25794x +25801x +25877x +25941x +25997x +26121x +26293x +26342x +26454x +26457x +26481x +26487x +26490x +26503x +26514x +26515x 26556x -26591 -26662 -26720 -26739 +26591x +26662x +26720x +26739x 26741x 26767x -26783 -26793 -26794 -26825 -26844 -26881 -26899 -26900 -26997 -27003 +26783x +26793x +26794x +26825x +26844x +26881x +26899x +26900x +26997x +27003x 27006x -27018 -27087 -27169 -27203 -27205 +27018x +27087x +27169x +27203x +27205x 27210x -27254 -27283 +27254X +27283X 27286 27291 27362 Modified: trunk/dynamic-docs/changelog/mysqld.xml =================================================================== --- trunk/dynamic-docs/changelog/mysqld.xml 2007-11-18 14:59:57 UTC (rev 8781) +++ trunk/dynamic-docs/changelog/mysqld.xml 2007-11-18 18:44:53 UTC (rev 8782) Changed blocks: 102, Lines Added: 177, Lines Deleted: 1299; 46573 bytes @@ -4940,33 +4940,7 @@ <logentry entrytype="bug"> - <tags> - <highlight type="cluster"/> - </tags> - <bugs> - <fixes bugid="26514"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - (Disk Data): A memory overflow could occur with tables having a - large amount of data stored on disk, or with queries using a - very high degree of parallelism on Disk Data tables. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="21007"/> </bugs> @@ -6347,39 +6321,6 @@ <tags> <highlight type="cluster"/> - <manual type="cluster"/> - <manual type="replication"/> - <manual type="MyISAM"/> - <manual type="InnoDB"/> - <manual type="mysqld"/> - </tags> - - <bugs> - <fixes bugid="26783"/> - </bugs> - - <versions> - <version ver="5.1.20"/> - </versions> - - <message> - - <para> - (Replication): When replicating <literal>MyISAM</literal> or - <literal>InnoDB</literal> tables to a MySQL Cluster, it was not - possible to determine exactly what had been applied following a - shutdown of the slave cluster or <command>mysqld</command> - process. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> <manual type="UPDATE IGNORE"/> </tags> @@ -9660,7 +9601,7 @@ <bugs> <cve ref="CVE-2006-4227"/> - <fixes bugid="26844"/> + <fixes bugid="18630"/> </bugs> <versions> @@ -9673,7 +9614,7 @@ <para> A stored routine created by one user and then made accessible to a different user using <literal>GRANT EXECUTE</literal> could be - executed by that user with the privileges of the routine's + executed by that user with the privileges of the routine's definer. </para> @@ -9683,11 +9624,17 @@ <logentry entrytype="bug"> + <tags> + <highlight type="replication"/> + </tags> + <bugs> <fixes bugid="26844"/> </bugs> <versions> + <version ver="5.0.40"/> + <version ver="5.0.41"/> <version ver="5.1.18"/> </versions> @@ -10422,9 +10369,10 @@ </bugs> <versions> + <version ver="5.0.38"/> <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.3"/> <version ver="5.1.17"/> - <version ver="5.0.38"/> </versions> <message> @@ -10902,6 +10850,7 @@ <versions> <version ver="5.1.15-ndb-6.1.3"/> + <version ver="5.1.16"/> </versions> <message> @@ -12275,34 +12224,7 @@ <logentry entrytype="feature"> - <tags> - <highlight type="cluster"/> - <manual type="ndb_restore"/> - </tags> - - <bugs> - <fixes bugid="26899"/> - </bugs> - <versions> - <version ver="5.0.40"/> - <version ver="5.0.41"/> - </versions> - - <message> - - <para> - It is now possible to restore selected databases or tables using - <command>ndb_restore</command>. - </para> - - </message> - - </logentry> - - <logentry entrytype="feature"> - - <versions> <version ver="5.0.1"/> </versions> @@ -13847,30 +13769,6 @@ <logentry entrytype="bug"> <tags> - <manual type="mysqldump"/> - </tags> - - <bugs> - <fixes bugid="26121"/> - </bugs> - - <versions> - <version ver="5.1.18"/> - </versions> - - <message> - - <para> - <command>mysqldump</command> could not dump the log tables. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="MyISAM"/> </tags> @@ -14644,37 +14542,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <manual type="tmpfs"/> - <manual type="O_DIRECT"/> - <manual type="mysqld"/> - </tags> - - <bugs> - <fixes bugid="26662"/> - </bugs> - - <versions> - <version ver="5.1.18"/> - </versions> - - <message> - - <para> - Creating a temporary table with InnoDB when using the - one-file-per-table setting, when the host filesystem for - temporary tables is <literal>tmpfs</literal> would cause an - assertion in <literal>mysqld</literal>. This was due to the use - of <literal>O_DIRECT</literal> when opening the temporary table - file. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -14720,6 +14587,7 @@ <versions> <version ver="5.1.19-ndb-6.2.3"/> + <version ver="5.1.20"/> </versions> <message> @@ -15367,32 +15235,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <manual type="initial"/> - </tags> - - <bugs> - <fixes bugid="26481"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.3"/> - </versions> - - <message> - - <para> - The failure of a data node when restarting it with - <option>--initial</option> could lead to failures of subsequent - data node restarts. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -16302,14 +16144,15 @@ <versions> <version ver="5.1.15-ndb-6.1.7"/> + <version ver="5.1.18"/> </versions> <message> <para> When restarting a data node following the creation of a large - number (~200) of Disk Data objects, the cluster could not assign - a node ID to the restarting node. + number of Disk Data objects (approximately 200 such objects), + the cluster could not assign a node ID to the restarting node. </para> </message> @@ -17872,6 +17715,7 @@ <versions> <version ver="5.1.15-ndb-6.1.6"/> + <version ver="5.1.17"/> </versions> <message> @@ -18036,6 +17880,7 @@ </bugs> <versions> + <version ver="5.0.40"/> <version ver="5.1.18"/> </versions> @@ -22254,6 +22099,7 @@ <versions> <version ver="5.0.40"/> <version ver="5.0.41"/> + <version ver="5.1.17"/> </versions> <message> @@ -22270,6 +22116,19 @@ </message> + <message ver="5.1.17"> + + <para> + Prefix lengths for columns in <literal>SPATIAL</literal> indexes + can no longer be specified. For tables created in older versions + of MySQL that have <literal>SPATIAL</literal> indexes containing + prefixed columns, dumping and reloading the table causes the + indexes to be created with no prefixes. (The full column width + of each column is indexed.) + </para> + + </message> + </logentry> <logentry entrytype="bug"> @@ -22851,10 +22710,9 @@ <tags> <manual type="cluster"/> - <manual type="false"/> - <manual type="true"/> <manual type="LockPagesInMainMemory"/> <highlight type="incompatiblechange"/> + <highlight type="cluster"/> </tags> <bugs> @@ -22862,7 +22720,9 @@ </bugs> <versions> - <version ver="5.1.15-ndb-6.1.1"/> + <version ver="5.0.36"/> + <version ver="5.0.37"/> + <version ver="5.1.15"/> </versions> <message> @@ -22870,9 +22730,8 @@ <para> The <literal>LockPagesInMainMemory</literal> configuration parameter has changed its type and possible values. For more - information, see <literal> - <link linkend="mysql-cluster-param-ndbd-definition-lockpagesinmainmemory">LockPagesInMainMemory</link> - </literal>. + information, see + <literal><link linkend="mysql-cluster-param-ndbd-definition-lockpagesinmainmemory">LockPagesInMainMemory</link></literal>. </para> <important> @@ -22885,8 +22744,8 @@ set to <literal>true</literal>, you should instead use <literal>1</literal> to obtain the same behavior as previously, or <literal>2</literal> to take advantage of new - functionality introduced with this release described in the - section cited above. + functionality introduced with this release, as described in + the section cited above. </para> </important> @@ -23349,37 +23208,6 @@ <tags> <highlight type="cluster"/> - <manual type="stderr"/> - <manual type="ndb_config"/> - <manual type="config-file"/> - <manual type="stdout"/> - </tags> - - <bugs> - <fixes bugid="25941"/> - </bugs> - - <versions> - <version ver="5.0.48"/> - </versions> - - <message> - - <para> - The output from <command>ndb_config - <option>--config-file=<replaceable>file</replaceable></option></command> - was sent to <literal>stdout</literal> rather than - <literal>stderr</literal>. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> <manual type="BLOB"/> </tags> @@ -23492,33 +23320,7 @@ <logentry entrytype="bug"> - <tags> - <manual type="cluster"/> - <highlight type="cluster"/> - </tags> - <bugs> - <fixes bugid="25711"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.1"/> - </versions> - - <message> - - <para> - Hosts in clusters with a large number of nodes could experience - excessive CPU usage while obtaining configuration data. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="27583"/> </bugs> @@ -35788,44 +35590,6 @@ <logentry entrytype="bug"> <tags> - <manual type="VARCHAR"/> - <manual type="MERGE"/> - <manual type="TINYINT"/> - <manual type="ALTER TABLE"/> - </tags> - - <bugs> - <fixes bugid="26881"/> - </bugs> - - <versions> - <version ver="4.1.23"/> - </versions> - - <message> - - <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. - Also, when the underlying tables contained a - <literal>TINYINT</literal> or <literal>CHAR(1)</literal> column, - the <literal>MERGE</literal> storage engine incorrectly reported - that they differed from the <literal>MERGE</literal> table in - certain cases. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="libmysqlclient"/> <manual type="mysql_create_db()"/> </tags> @@ -37610,9 +37374,9 @@ </bugs> <versions> - <version ver="5.0.41"/> - <version ver="5.1.17"/> <version ver="5.0.38"/> + <version ver="5.1.15-ndb-6.1.5"/> + <version ver="5.1.17"/> </versions> <message> @@ -37793,34 +37557,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - <manual type="ndb_restore"/> - </tags> - - <bugs> - <fixes bugid="26739"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.4"/> - </versions> - - <message> - - <para> - An inadvertent use of unaligned data caused - <command>ndb_restore</command> to fail on some 64-bit platforms, - including Sparc and Itanium-2. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -38067,33 +37803,7 @@ <logentry entrytype="bug"> - <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - <bugs> - <fixes bugid="26591"/> - </bugs> - - <versions> - <version ver="5.1.18-ndb-6.2.1"/> - </versions> - - <message> - - <para> - The Cluster table handler did not set bits in null bytes - correctly. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="18386"/> </bugs> @@ -41915,32 +41625,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="DROP INDEX"/> - </tags> - - <bugs> - <fixes bugid="25877"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - (Disk Data): <literal>DROP INDEX</literal> on a Disk Data table - did not always move data from memory into the tablespace. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="Windows"/> </tags> @@ -42517,56 +42201,6 @@ </logentry> - <logentry entrytype="feature"> - - <tags> - <highlight type="cluster"/> - <highlight type="incompatiblechange"/> - <manual type="cluster"/> - <manual type="false"/> - <manual type="true"/> - <manual type="LockPagesInMainMemory"/> - </tags> - - <bugs> - <fixes bugid="25686"/> - </bugs> - - <versions> - <version ver="5.1.15"/> - <version ver="5.0.36"/> - <version ver="5.0.37"/> - </versions> - - <message> - - <para> - The <literal>LockPagesInMainMemory</literal> configuration - parameter has changed its type and possible values. For more - information, see <literal> - <link linkend="mysql-cluster-param-ndbd-definition-lockpagesinmainmemory">LockPagesInMainMemory</link> - </literal>. - </para> - - <important> - <para> - The values <literal>true</literal> and - <literal>false</literal> are no longer accepted for this - parameter. If you were using this parameter and had it set to - <literal>false</literal> in a previous release, you must - change it to <literal>0</literal>. If you had this parameter - set to <literal>true</literal>, you should instead use - <literal>1</literal> to obtain the same behavior as - previously, or <literal>2</literal> to take advantage of new - functionality introduced with this release described in the - section cited above. - </para> - </important> - - </message> - - </logentry> - <logentry entrytype="bug"> <tags> @@ -42880,34 +42514,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="UNDO_BUFFER_SIZE"/> - <manual type="INITIAL_SIZE"/> - </tags> - - <bugs> - <fixes bugid="25743"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - (Disk Data): When creating a log file group, setting - <literal>INITIAL_SIZE</literal> to less than - <literal>UNDO_BUFFER_SIZE</literal> caused data nodes to crash. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="replication"/> <manual type="partitioning"/> </tags> @@ -45288,6 +44894,8 @@ <versions> <version ver="5.0.40"/> <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.5"/> + <version ver="5.1.15-ndb-6.1.6"/> <version ver="5.1.17"/> </versions> @@ -45300,6 +44908,37 @@ </message> + <message ver="5.1.15-ndb-6.1.5"> + + <para> + <command>mysqld</command> processes would sometimes crash under + high load. + </para> + + <note> + <para> + This fix was reverted in MySQL 5.1.15-ndb-6.1.6. + </para> + </note> + + </message> + + <message ver="5.1.15-ndb-6.1.6"> + + <para> + <command>mysqld</command> processes would sometimes crash under + high load. + </para> + + <note> + <para> + This fix improves on and replaces a fix for this bug that was + made in MySQL 5.1.15-ndb-6.1.5. + </para> + </note> + + </message> + </logentry> <logentry entrytype="bug"> @@ -46145,6 +45784,7 @@ <versions> <version ver="5.0.46"/> + <version ver="5.1.19-ndb-6.2.3"/> <version ver="5.1.20"/> </versions> @@ -46327,7 +45967,7 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> + <highlight type="clusterapi"/> </tags> <bugs> @@ -46337,16 +45977,17 @@ <versions> <version ver="5.0.40"/> <version ver="5.0.41"/> + <version ver="5.1.18-ndb-6.2.1"/> <version ver="5.1.18"/> </versions> <message> <para> - (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. + 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. </para> </message> @@ -47930,37 +47571,7 @@ <logentry entrytype="bug"> - <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - <manual type="LockPagesInMemory"/> - </tags> - <bugs> - <fixes bugid="26454"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.3"/> - </versions> - - <message> - - <para> - 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. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="18930"/> </bugs> @@ -48542,12 +48153,17 @@ <logentry entrytype="bug"> + <tags> + <highlight type="cluster"/> + </tags> + <bugs> <fixes bugid="26490"/> </bugs> <versions> <version ver="5.1.15-ndb-6.1.3"/> + <version ver="5.1.16"/> </versions> <message> @@ -50460,8 +50076,9 @@ </bugs> <versions> - <version ver="5.0.41"/> <version ver="5.0.38"/> + <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.3"/> <version ver="5.1.16"/> </versions> @@ -50469,9 +50086,9 @@ <para> Under some circumstances, following the restart of a management - node, all cluster data nodes would connect to it normally, but - some of them subsequently failed to log any events to the - management node. + node, all data nodes would connect to it normally, but some of + them subsequently failed to log any events to the management + node. </para> </message> @@ -51211,27 +50828,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="26457"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.3"/> - </versions> - - <message> - - <para> - Takeover for local checkpointing due to multiple failures of - master nodes was sometimes handled incorrectly. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <highlight type="diskdata"/> <manual type="cluster"/> @@ -54999,36 +54595,6 @@ <logentry entrytype="bug"> <tags> - <manual type="mysql_thread_end()"/> - <manual type="Windows"/> - <manual type="mysql_thread_init()"/> - </tags> - - <bugs> - <fixes bugid="25621"/> - </bugs> - - <versions> - <version ver="5.1.20"/> - </versions> - - <message> - - <para> - On Windows, an application that called - <function role="capi">mysql_thread_init()</function> but forgot - to call <function role="capi">mysql_thread_end()</function> - would get this error: <literal>Error in - my_thread_global_end()</literal> - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="replication"/> </tags> @@ -57198,14 +56764,15 @@ </bugs> <versions> + <version ver="5.0.48"/> <version ver="5.1.21"/> </versions> <message> <para> - Warnings and errors generated by <command>ndb_config</command> - <option>--config-file=<replaceable>file</replaceable> </option> + Warnings and errors generated by <command>ndb_config + <option>--config-file=<replaceable>file</replaceable></option></command> were sent to <literal>stdout</literal>, rather than to <literal>stderr</literal>. </para> @@ -58930,29 +58497,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="26720"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.5"/> - </versions> - - <message> - - <para> - 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. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <highlight type="cluster"/> <manual type="cluster"/> @@ -59251,12 +58795,35 @@ </bugs> <versions> + <version ver="4.1.23"/> <version ver="5.0.36sp1"/> + <version ver="5.0.38"/> <version ver="5.0.41"/> <version ver="5.1.17"/> - <version ver="5.0.38"/> </versions> + <message ver="4.1.23"> + + <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. + </para> + + <para> + In addition, when the underlying tables contained a + <literal>TINYINT</literal> or <literal>CHAR(1)</literal> column, + the <literal>MERGE</literal> storage engine incorrectly reported + that they differed from the <literal>MERGE</literal> table in + certain cases. + </para> + + </message> + <message> <para> @@ -59384,16 +58951,16 @@ <para> The parser now rejects this invalid construct, but if you upgrade in place (without dumping and reloading your databases), - existing handlers that contain the construct still are invalid - <emphasis>even if they appear to function as you - expect</emphasis> and should be rewritten. + existing handlers that contain the construct are still invalid + — <emphasis>even if they appear to function as you + expect</emphasis> — and should be rewritten. </para> <para> - To find affected handlers, use mysqldump to dump all stored - functions and procedures, triggers, and events. Then attempt to - reload them into an upgraded server. Handlers that contain - illegal label references will be rejected. + To find affected handlers, use <command>mysqldump</command> to + dump all stored functions and procedures, triggers, and events. + Then attempt to reload them into an upgraded server. Handlers + that contain illegal label references will be rejected. </para> <para> @@ -59793,36 +59360,6 @@ <logentry entrytype="bug"> <tags> - <manual type="mysqld"/> - </tags> - - <bugs> - <fixes bugid="26825"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.6"/> - </versions> - - <message> - - <para> - <command>mysqld</command> processes would sometimes crash under - high load. - </para> - - <para> - This improves on and replaces the fix for this bug that was made - in MySQL 5.1.15-ndb-6.1.5. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="lower_case_table_names"/> </tags> @@ -60520,6 +60057,7 @@ <versions> <version ver="5.0.38"/> <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.4"/> <version ver="5.1.16"/> </versions> @@ -60936,34 +60474,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <manual type="auto_increment_offset"/> - <manual type="auto_increment_increment"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="26342"/> - </bugs> - - <versions> - <version ver="5.1.19-ndb-6.2.3"/> - </versions> - - <message> - - <para> - <literal>auto_increment_increment</literal> and - <literal>auto_increment_offset</literal> are now supported for - <literal>NDB</literal> tables. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -61698,32 +61208,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="25801"/> - </bugs> - - <versions> - <version ver="5.1.16"/> - </versions> - - <message> - - <para> - An appropriate error message was not provided when there was - insufficient REDO log file space for the cluster to start. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="innodb_locks_unsafe_for_binlog"/> <manual type="InnoDB"/> </tags> @@ -63686,8 +63170,9 @@ </bugs> <versions> - <version ver="5.0.41"/> <version ver="5.0.38"/> + <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.3"/> <version ver="5.1.16"/> </versions> @@ -66735,11 +66220,17 @@ <logentry entrytype="bug"> + <tags> + <highlight type="cluster"/> + <manual type="mysqld"/> + </tags> + <bugs> <fixes bugid="26997"/> </bugs> <versions> + <version ver="5.1.15-ndb-6.1.5"/> <version ver="5.1.17"/> </versions> @@ -68623,6 +68114,7 @@ <tags> <highlight type="cluster"/> <manual type="cluster"/> + <manual type="INFORMATION_SCHEMA"/> </tags> <bugs> @@ -68630,6 +68122,7 @@ </bugs> <versions> + <version ver="5.1.22-ndb-6.2.5"/> <version ver="5.1.23"/> <version ver="5.0.50"/> </versions> @@ -73297,31 +72790,6 @@ <logentry entrytype="bug"> <tags> - <manual type="mysqld"/> - </tags> - - <bugs> - <fixes bugid="26825"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.5"/> - </versions> - - <message> - - <para> - <command>mysqld</command> processes would sometimes crash under - high load. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="InnoDB"/> </tags> @@ -73511,38 +72979,7 @@ <logentry entrytype="bug"> - <tags> - <highlight type="clusterapi"/> - <highlight type="clusterreplication"/> - <manual type="cluster"/> - <manual type="VARCHAR"/> - </tags> - <bugs> - <fixes bugid="25794"/> - </bugs> - - <versions> - <version ver="5.1.16"/> - </versions> - - <message> - - <para> - A delete and a read peformed as part of the same operation could - cause one or more of the cluster's data nodes to crash. - This could occur when the operation affected more than 5 columns - concurrently, or when one or more of the columns was of the - <literal>VARCHAR</literal> type and was stored on disk. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="22129"/> </bugs> @@ -75138,6 +74575,7 @@ <versions> <version ver="5.0.40"/> <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.6"/> <version ver="5.1.17"/> </versions> @@ -76696,32 +76134,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="replication"/> - </tags> - - <bugs> - <fixes bugid="25755"/> - </bugs> - - <versions> - <version ver="5.1.15"/> - </versions> - - <message> - - <para> - (Replication): Certain errors in replication setups could lead - to subsequent node failures. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="DATE"/> </tags> @@ -77583,6 +76995,7 @@ <versions> <version ver="5.0.41"/> <version ver="5.0.38"/> + <version ver="5.1.15-ndb-6.1.3"/> <version ver="5.1.16"/> </versions> @@ -79783,8 +79196,10 @@ </bugs> <versions> - <version ver="5.0.41"/> <version ver="5.0.38"/> + <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.3"/> + <version ver="5.1.16"/> </versions> <message> @@ -80004,33 +79419,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="diskdata"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="25741"/> - </bugs> - - <versions> - <version ver="5.1.18"/> - </versions> - - <message> - - <para> - When restarting a data node following the creation of a large - number (~200) of Disk Data objects, the cluster could not assign - a node ID to the restarting node. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="mysqldump"/> <manual type="skip-events"/> <manual type="skip-events --all-databases"/> @@ -80342,27 +79730,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="26503"/> - </bugs> - - <versions> - <version ver="5.0.41"/> - </versions> - - <message> - - <para> - The parser accepted illegal code in SQL exception handlers, - leading to a crash at runtime when executing the code. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="LTRIM"/> <manual type="DECIMAL"/> @@ -83285,28 +82652,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="26844"/> - </bugs> - - <versions> - <version ver="5.0.40"/> - <version ver="5.0.41"/> - </versions> - - <message> - - <para> - Out-of-memory errors for slave I/O threads were not reported. - Now they are written to the error log. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="LAST_INSERT_ID"/> <manual type="AUTO_INCREMENT"/> @@ -85401,34 +84746,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> - </tags> - - <bugs> - <fixes bugid="26490"/> - </bugs> - - <versions> - <version ver="5.1.16"/> - </versions> - - <message> - - <para> - The <errorname>InvalidUndoBufferSize</errorname> error used the - same error code (<errorcode>763</errorcode>) as the - <errorname>IncompatibleVersions</errorname> error. - <errorname>InvalidUndoBufferSize</errorname> now uses its own - error code (<errorcode>779</errorcode>). - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -86789,6 +86106,7 @@ <versions> <version ver="5.1.15-ndb-6.1.3"/> + <version ver="5.1.17"/> </versions> <message> @@ -88479,32 +87797,6 @@ </logentry> - <logentry entrytype="feature"> - - <tags> - <highlight type="cluster"/> - <manual type="ndb_restore"/> - </tags> - - <bugs> - <fixes bugid="26899"/> - </bugs> - - <versions> - <version ver="5.1.18"/> - </versions> - - <message> - - <para> - It is now possible to restore selected databases or tables using - <command>ndb_restore</command>. - </para> - - </message> - - </logentry> - <logentry entrytype="bug"> <tags> @@ -88815,28 +88107,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="27283"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.6"/> - </versions> - - <message> - - <para> - 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. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="Mac OS X"/> </tags> @@ -92357,27 +91627,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="27003"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.6"/> - </versions> - - <message> - - <para> - The failure of a data node while restarting could cause other - data nodes to hang or crash. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="tinfo"/> </tags> @@ -94029,6 +93278,7 @@ <versions> <version ver="5.1.15-ndb-6.1.7"/> + <version ver="5.1.18"/> </versions> <message> @@ -94939,32 +94189,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="25997"/> - </bugs> - - <versions> - <version ver="5.1.16"/> - </versions> - - <message> - - <para> - A memory leak could cause problems during a node or cluster - shutdown or failure. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="Windows"/> <manual type="mysqlcheck.exe"/> <manual type="mysql_upgrade.exe"/> @@ -96549,6 +95773,7 @@ <highlight type="diskdata"/> <manual type="UNDO_BUFFER_SIZE"/> <manual type="INITIAL_SIZE"/> + <manual type="cluster"/> </tags> <bugs> @@ -96557,6 +95782,7 @@ <versions> <version ver="5.1.15-ndb-6.1.5"/> + <version ver="5.1.17"/> </versions> <message> @@ -98023,32 +97249,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> - <manual type="mysqld"/> - </tags> - - <bugs> - <fixes bugid="27169"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - <command>mysqld</command> could crash shortly after a data node - failure following certain DML operations. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -99120,35 +98320,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="26793"/> - </bugs> - - <versions> - <version ver="5.1.22-ndb-6.2.5"/> - </versions> - - <message> - - <para> - An attempt to perform a <literal>SELECT ... FROM - INFORMATION_SCHEMA.TABLES</literal> whose result included - information about <literal>NDB</literal> tables for which the - user had no privileges could crash the MySQL Server on which the - query was performed. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <versions> @@ -100382,6 +99553,7 @@ <versions> <version ver="5.1.15-ndb-6.1.3"/> + <version ver="5.1.17"/> </versions> <message> @@ -100661,34 +99833,7 @@ <logentry entrytype="bug"> - <tags> - <highlight type="diskdata"/> - <manual type="cluster"/> - <manual type="INITIAL_SIZE"/> - </tags> - <bugs> - <fixes bugid="26487"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - Use of a tablespace whose <literal>INITIAL_SIZE</literal> was - greater than 1 GB could cause the cluster to crash. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <bugs> <fixes bugid="26625"/> </bugs> @@ -104045,34 +103190,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="26293"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.3"/> - </versions> - - <message> - - <para> - Under some circumstances, following the restart of a management - node, all cluster data nodes would connect to it normally, but - some of them subsequently failed to log any events to the - management node. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="collation"/> <manual type="DELETE"/> <manual type="FULLTEXT"/> @@ -104336,34 +103453,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="27254"/> - </bugs> - - <versions> - <version ver="5.1.18-ndb-6.2.1"/> - </versions> - - <message> - - <para> - After putting the cluster in single user mode from one MySQL - server, trying to drop an <literal>NDB</literal> table from a - second MySQL server connected to the same cluster would cause - the second MySQL server to hang. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="replication"/> <manual type="FLUSH LOGS"/> </tags> @@ -104467,35 +103556,6 @@ </logentry> - <logentry entrytype="feature"> - - <tags> - <manual type="SPATIAL"/> - </tags> - - <bugs> - <fixes bugid="26794"/> - </bugs> - - <versions> - <version ver="5.1.17"/> - </versions> - - <message> - - <para> - Prefix lengths for columns in <literal>SPATIAL</literal> indexes - no longer can be specified. For tables created in older versions - of MySQL that have <literal>SPATIAL</literal> indexes containing - prefixed columns, dumping and reloading the table causes the - indexes to be created with no prefixes. (The full column width - of each column is indexed.) - </para> - - </message> - - </logentry> - <logentry entrytype="bug"> <tags> @@ -106411,6 +105471,7 @@ <logentry entrytype="bug"> <tags> + <highlight type="cluster"/> <manual type="mysqld"/> </tags> @@ -106419,8 +105480,8 @@ </bugs> <versions> - <version ver="5.1.18-ndb-6.2.1"/> <version ver="5.1.15-ndb-6.1.6"/> + <version ver="5.1.17"/> </versions> <message> @@ -107761,6 +106822,7 @@ <tags> <highlight type="clusterreplication"/> + <manual type="cluster"/> <manual type="replication"/> </tags> @@ -107769,13 +106831,13 @@ </bugs> <versions> - <version ver="5.1.15-ndb-6.1.1"/> + <version ver="5.1.15"/> </versions> <message> <para> - Certain errors in replication setups could lead to subsequent + Certain errors in replication setups could lead to unexpected node failures. </para> @@ -110167,6 +109229,7 @@ <manual type="tmpfs"/> <manual type="O_DIRECT"/> <manual type="mysqld"/> + <manual type="InnoDB"/> </tags> <bugs> @@ -110176,14 +109239,15 @@ <versions> <version ver="5.0.42"/> <version ver="5.0.45"/> + <version ver="5.1.18"/> </versions> <message> <para> Creating a temporary table with InnoDB when using the - one-file-per-table setting, when the host filesystem for - temporary tables is <literal>tmpfs</literal> would cause an + one-file-per-table setting, and when the host filesystem for + temporary tables was <literal>tmpfs</literal>, would cause an assertion within <literal>mysqld</literal>. This was due to the use of <literal>O_DIRECT</literal> when opening the temporary table file. @@ -110308,6 +109372,7 @@ </bugs> <versions> + <version ver="5.1.15-ndb-6.1.6"/> <version ver="5.1.17"/> </versions> @@ -111937,33 +111002,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="FSCLOSECONF"/> - </tags> - - <bugs> - <fixes bugid="26515"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.3"/> - </versions> - - <message> - - <para> - An invalid pointer was returned following a - <literal>FSCLOSECONF</literal> signal when accessing the REDO - logs during a node restart or system restart. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="ORDER BY"/> <manual type="partitioning"/> </tags> @@ -117896,36 +116934,6 @@ </logentry> - <logentry entrytype="feature"> - - <tags> - <highlight type="cluster"/> - <manual type="print_data"/> - <manual type="ndb_restore"/> - </tags> - - <bugs> - <fixes bugid="26900"/> - </bugs> - - <versions> - <version ver="5.0.40"/> - <version ver="5.0.41"/> - </versions> - - <message> - - <para> - Several options have been added for use with - <command>ndb_restore <option>--print_data</option></command> to - facilitate the creation of data dump files. See - <xref linkend="mysql-cluster-restore"/>, for more information. - </para> - - </message> - - </logentry> - <logentry entrytype="bug"> <bugs> @@ -118860,7 +117868,7 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> + <highlight type="clusterapi"/> </tags> <bugs> @@ -118868,13 +117876,14 @@ </bugs> <versions> + <version ver="5.1.15-ndb-6.1.6"/> <version ver="5.1.17"/> </versions> <message> <para> - A delete operation using a scan following by an insert using a + A delete operation using a scan followed by an insert using a scan could cause a data node to fail. </para> @@ -120148,6 +119157,7 @@ <versions> <version ver="5.0.40"/> <version ver="5.0.41"/> + <version ver="5.1.15-ndb-6.1.6"/> <version ver="5.1.17"/> </versions> @@ -123997,32 +123007,6 @@ <logentry entrytype="bug"> <tags> - <highlight type="cluster"/> - <manual type="cluster"/> - </tags> - - <bugs> - <fixes bugid="27087"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.6"/> - </versions> - - <message> - - <para> - The same failed request from an API node could be handled by the - cluster multiple times, resulting in reduced performance. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - - <tags> <manual type="BLOB"/> <manual type="TEXT"/> </tags> @@ -124442,27 +123426,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="27203"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.6"/> - </versions> - - <message> - - <para> - A delete operation using a scan following by an insert using a - scan could cause a data node to fail. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="SSL"/> <manual type="libmysqlclient"/> @@ -124493,38 +123456,6 @@ </logentry> - <logentry entrytype="feature"> - - <tags> - <highlight type="cluster"/> - <manual type="print_data"/> - <manual type="mysqldump"/> - <manual type="ndb_restore"/> - </tags> - - <bugs> - <fixes bugid="26900"/> - </bugs> - - <versions> - <version ver="5.1.18"/> - </versions> - - <message> - - <para> - Several options have been added for use with - <command>ndb_restore <option>--print_data</option> </command> to - facilitate the creation of structured data dump files. These - options can be used to make dumps made using - <command>ndb_restore</command> more like those produced by - <command>mysqldump</command>. - </para> - - </message> - - </logentry> - <logentry entrytype="bug"> <tags> @@ -125501,33 +124432,6 @@ </logentry> - <logentry entrytype="bug"> - - <tags> - <highlight type="clusterapi"/> - </tags> - - <bugs> - <fixes bugid="27018"/> - </bugs> - - <versions> - <version ver="5.1.18-ndb-6.2.1"/> - </versions> - - <message> - - <para> - 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. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -127162,6 +126066,7 @@ <version ver="5.0.45"/> <version ver="5.0.44"/> <version ver="5.1.18"/> + <version ver="5.1.20"/> </versions> <message> @@ -127173,6 +126078,18 @@ </message> + <message ver="5.1.20"> + + <para> + On Windows, an application that called + <function role="capi">mysql_thread_init()</function> but forgot + to call <function role="capi">mysql_thread_end()</function> + would get this error: <errortext>Error in + my_thread_global_end()</errortext>. + </para> + + </message> + </logentry> <logentry entrytype="bug"> @@ -129795,6 +128712,7 @@ <versions> <version ver="5.1.15-ndb-6.1.1"/> + <version ver="5.1.16"/> </versions> <message> @@ -130707,6 +129625,7 @@ </bugs> <versions> + <version ver="5.1.15-ndb-6.1.7"/> <version ver="5.1.18"/> </versions> @@ -135709,28 +134628,6 @@ </logentry> - <logentry entrytype="bug"> - - <bugs> - <fixes bugid="27205"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.7"/> - </versions> - - <message> - - <para> - Performing a delete followed by an insert during a local - checkpoint could cause a <errortext>Rowid already - allocated</errortext> error. - </para> - - </message> - - </logentry> - <logentry entrytype="feature"> <tags> @@ -136463,27 +135360,6 @@ <logentry entrytype="bug"> - <bugs> - <fixes bugid="26997"/> - </bugs> - - <versions> - <version ver="5.1.15-ndb-6.1.5"/> - </versions> - - <message> - - <para> - Creating a table on one SQL node while in single user mode - caused other SQL nodes to crash. - </para> - - </message> - - </logentry> - - <logentry entrytype="bug"> - <tags> <manual type="mysqld_safe"/> <manual type="root"/> @@ -136577,6 +135453,7 @@ <highlight type="diskdata"/> <highlight type="clusterapi"/> <manual type="cluster"/> + <manual type="VARCHAR"/> </tags> <bugs> @@ -136585,6 +135462,7 @@ <versions> <version ver="5.1.15-ndb-6.1.1"/> + <version ver="5.1.16"/> </versions> <message>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r8782 - trunk/dynamic-docs/changelog | jon | 18 Nov |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.095 sec. using MySQL 5.1.14-beta-log