Author: mcbrown
Date: 2007-11-28 08:34:28 +0100 (Wed, 28 Nov 2007)
New Revision: 8929
Log:
Automatic update from openbugs
Modified:
trunk/dynamic-docs/open-bugs/mysqld.xml
Modified: trunk/dynamic-docs/open-bugs/mysqld.xml
===================================================================
--- trunk/dynamic-docs/open-bugs/mysqld.xml 2007-11-28 07:33:41 UTC (rev 8928)
+++ trunk/dynamic-docs/open-bugs/mysqld.xml 2007-11-28 07:34:28 UTC (rev 8929)
Changed blocks: 18, Lines Added: 1825, Lines Deleted: 0; 41360 bytes
@@ -9,6 +9,46 @@
</tags>
<bugs>
+ <fixes bugid="29605"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: --local-infile=0 checks can be bypassed by sending a
+ <literal>FETCH LOCAL FILE</literal> response
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ --local-infile=0 disables support for LOAD LOCAL INFILE in
+ MySQL clients. However, this is currently enforced only on
+ the server, which means that a "fake" server (that is, one
+ that disregards the --local-infile setting) can read any
+ files to which clients have access. It is assumed that this
+ issue affects all MySQL client libraries and applications.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="C API"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30472"/>
</bugs>
@@ -45,10 +85,206 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Client"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25162"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Backing up <literal>DB</literal> from 5.1 adds
+ '<literal>USING BTREE</literal>' to KEYs on table creates
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The problem caused by this issue is that it is not possible
+ to restore a dump of a 5.1 database to a 5.0 server without
+ hand-editing the table definitions in the dump file. Another
+ (and simpler) workaround is to create the dump using the
+ mysqldump --compatible=mysql40 option or the Compatibility
+ Mode in MySQL Administrator.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Client"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30679"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: 5.1 name encoding not performed for views during
+ upgrade
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ mysql_upgrade/mysqlcheck did not properly re-encode names
+ for views when upgrading from 5.0 to 5.1. Workaround: Drop
+ and recreate affected views.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Client"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30946"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: mysqldump silently ignores --default-character-set when
+ used with --tab
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Dumps for tables containing columns with different character
+ sets would not be reloadable. To deal with this, a CHARACTER
+ SET clause is being added to SELECT ... INTO OUTFILE (which
+ mysqldump uses) so that all columns will be converted to a
+ single character set on output. The same character set can
+ be specified for LOAD DATA to enable the dump file to be
+ reloaded.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Connector/J"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20491"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Illegal codepage usage while
+ DatabaseMetaData.getColumns()
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If a table column name contains German umlauts, the method
+ DatabaseMetaData.getColumns() returns a ResultSet that
+ contains unusable column names. This issue is known to occur
+ using Connector/J 3.1 or newer. Workaround: Use a version of
+ the Connector previous to 3.1.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server"/>
</tags>
<bugs>
+ <fixes bugid="21476"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <fixedin ver="5.1.20"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: stack overflow crashes server; error-message stack
+ reservation too small
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The minimum default thread stack size was too small on
+ platforms and could cause server crashes. Workaround: Use
+ --thread-stack=N to increase the stack size.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server"/>
+ </tags>
+
+ <bugs>
<fixes bugid="22351"/>
</bugs>
@@ -88,6 +324,38 @@
</tags>
<bugs>
+ <fixes bugid="22563"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: MySQL service won't start on Vista without elevated
+ privileges
+ </para>
+
+ <itemizedlist>
+
+ <listitem></listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server"/>
+ </tags>
+
+ <bugs>
<fixes bugid="29419"/>
</bugs>
@@ -129,6 +397,45 @@
</tags>
<bugs>
+ <fixes bugid="29553"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="6.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Specifying a query cache of 5GB causes the server to
+ crash
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This problem is known to occur only on 64-bit Windows
+ pltforms. The workaround is to increase the size of the
+ Windows page file, or to decrease the amount of physical
+ memory on the machine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server"/>
+ </tags>
+
+ <bugs>
<fixes bugid="29908"/>
</bugs>
@@ -169,6 +476,42 @@
</tags>
<bugs>
+ <fixes bugid="30355"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Incorrect ordering of <literal>UDF</literal> results
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Under some circumstances, a UDF initialization function
+ could be passed incorrect argument lengths.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30897"/>
</bugs>
@@ -241,10 +584,85 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20786"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: mysqldump always includes
+ <literal>AUTO_INCREMENT</literal>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Using mysqldump to dump your data or schema automatically
+ includes the AUTO_INCREMENT value for a table if the current
+ AUTO_INCREMENT value is greater than one.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: Charsets"/>
</tags>
<bugs>
+ <fixes bugid="29562"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: default collation of ucs2_unicode_ci crashes slave
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ With a master using ucs2 as the default character set, a
+ slave can in some cases end up with ucs2 as its
+ character_set_client value, and ucs2 is not supported for
+ character_set_client. Workaround: Use non-ucs2 character set
+ as master default.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Charsets"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30981"/>
</bugs>
@@ -434,6 +852,84 @@
</tags>
<bugs>
+ <fixes bugid="28445"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Heartbeat does not start until first
+ <literal>API_REGREQ</literal> is recevied
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If an API or management node restarts or a network failure
+ occurs, there is a short interval before data nodes can
+ detect this, which results in a lingering connection.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28647"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: backup will run forever if disk full and later write
+ succes will kill ndb node
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A Cluster backup fails to stop on its own if the disk on the
+ data node runs out of space. Workaround: Monitor data node
+ disk usage during Cluster backups. Note: A fix for this
+ issue has been committed and is expected to appear in the
+ next 5.1 release.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Cluster"/>
+ </tags>
+
+ <bugs>
<fixes bugid="29390"/>
</bugs>
@@ -470,6 +966,87 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: ClusterDD"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29186"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: write >4gb into 1 datafile on a 32-bit computer,
+ offset wraps causing corruption
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Creating a Disk Data log file or data file larger than 4 GB
+ on a host running a 32-bit operating system leads to
+ filesystem corruption on the host. Since this is a
+ limitation of 32-bit operating systems, the workaround is
+ not to create Disk Data files which are greater than 4 GB in
+ size on such platforms. In the future, we plan to disallow
+ statements creating Disk Data files whose size is greater
+ than 4 GB on 32-bit hosts.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: ClusterRep"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30529"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="6.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>NDB</literal> does not use default values
+ extra columns in new rows
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This issue manifests itself when, in Cluster replication, a
+ table on the slave is created having extra columns as
+ compared to the same table on the master.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: Compiling"/>
</tags>
@@ -514,6 +1091,41 @@
</tags>
<bugs>
+ <fixes bugid="17612"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: AIX5.2 64Bit InnoDb storage engine gets disabled
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The InnoDB stprage engine is intermittently disabled due to
+ a build issue related to the AIX linker.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Compiling"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30296"/>
</bugs>
@@ -784,6 +1396,46 @@
</tags>
<bugs>
+ <fixes bugid="26180"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Can't add columns to tables created with utf8 (regular)
+ text indexes
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The workaround is either (1) to create all columns in such
+ tables before adding indexes on UTF-8 TEXT columns, or as
+ part of the same CREATE TABLE statement, or (2) to create a
+ new table using CREATE SELECT (including any new column
+ definitions) and then dropping the old table and renaming
+ the new one.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: General"/>
+ </tags>
+
+ <bugs>
<fixes bugid="28687"/>
</bugs>
@@ -860,6 +1512,44 @@
</tags>
<bugs>
+ <fixes bugid="30889"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: filesort and order by with float/numeric crashes server
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The implementation of ROUND() for DECIMAL/NUMERIC arguments
+ could produce results where scale > precision, or where
+ scale larger than the maximum allowable scale. One symptom
+ is a crash when ORDER BY refers to an expression with
+ ROUND().
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: General"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30942"/>
</bugs>
@@ -894,10 +1584,243 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29157"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>UPDATE</literal>, changed rows incorrect
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When updating rows within an InnoDB, the 'rows changed'
+ information returned during an UPDATE statement only shows
+ the number of rows where the data was updated. If the update
+ value and the existing value are the same, then the rows
+ changed counter is not updated. One workaround is to
+ explicitly only change records that do not match the new
+ data.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Installing"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24853"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Default port not added to Vista firewall exceptions
+ list
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The effect of this bug is that remote access cannot be
+ enabled automatically for MySQL running on a Windows Vista
+ host. This is an installer issue. The workaround is to add
+ an exception for port 3306 to the Windows Wista firewall
+ manually.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Installing"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28628"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Config Wizard can't connect (race condition)
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ During the Security Settings phase, a Connection Error can
+ occur because the installer tries to proceed before the
+ MySQL Server being installed is fully started. Workaround:
+ wait a few moments, then click Retry in the error dialog.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Installing"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30487"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: mysql_upgrade reports misleading errors
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ After an upgrade from 5.0 to 5.1, running mysql_upgrade can
+ result in error messages about the general_log table not
+ existing. This does not prevent mysql_upgrade from
+ completing, but the messages give the impression that the
+ upgrade may not have been successful.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Installing"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30916"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: mysql_install_db file path issues
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The program looks for the error message file in the wrong
+ place. A workaround is to create a symlink in the location
+ expected by the program that points to the actual location.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: I_S"/>
</tags>
<bugs>
+ <fixes bugid="19588"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>INFORMATION_SCHEMA</literal> performs much too
+ slow on large servers
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Queries against the INFORMATION_SCHEMA database on servers
+ with thousands or greater numbers of databases/tables can
+ take many minutes to execute. Workaround: Use SHOW
+ statements (such as SHOW TABLES) in such cases where
+ possible. Note: A patch for this issue has been committed
+ since the 5.1.22 release.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: I_S"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30689"/>
</bugs>
@@ -1012,6 +1935,164 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: Merge"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26377"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Deadlock with <literal>MERGE</literal> and
+ <literal>FLUSH TABLE</literal>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A deadlock can be created if use LOCK TABLES simultaneously
+ on a MERGE and related MYISAM table and then run FLUSH
+ TABLE, but only if specify the MERGE table before the
+ corresponding MYISAM table in the LOCK TABLES statement.
+ Specifying the MYISAM table before the MERGE table does not
+ cause the same problem.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Merge"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26379"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Combination of <literal>FLUSH TABLE</literal> and
+ <literal>REPAIR TABLE</literal> corrupts a
+ <literal>MERGE</literal> table
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A combination of factors is involved in this issue: (1) the
+ table must be a MERGE table; (2) perform the statements LOCK
+ TABLE, REPAIR TABLE, and FLUSH TABLE on the merge and base
+ tables; (3) perform INSERTs from multiple threads into the
+ merge table. A fix for this bug has been prepared and is
+ expected to appear in 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Merge"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26867"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>LOCK TABLES</literal> +
+ <literal>REPAIR</literal> + merge table result in memory/cpu
+ hogging
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Using a MERGE table, issuing a REPAIR TABLE on one
+ connection while a LOCK TABLES statement is in place and an
+ INSERT statement on the same table is waiting on another
+ connection causes signficant CPU/memory usage.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Merge"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30275"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Merge tables: flush tables or unlock tables causes
+ server to crash
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ See description for Bug #26379.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: MyISAM"/>
</tags>
@@ -1174,6 +2255,48 @@
</tags>
<bugs>
+ <fixes bugid="29258"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Partitions: search fails for maximum unsigned bigint
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If you create a table with PARTITION BY
+ RANGE(unsigned_bigint_column) and PARTITION ... VALUES LESS
+ THAN MAXVALUE, then try to insert the maximum possible value
+ for BIGINT UNSIGNED (18446744073709551615), the INSERT
+ statement apparently succeeds (in some cases with a warning,
+ in others without one), but nothing is inserted into the
+ table; the value is not truncated, and the statement does
+ not produce an error.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Partition"/>
+ </tags>
+
+ <bugs>
<fixes bugid="29444"/>
</bugs>
@@ -1213,6 +2336,44 @@
</tags>
<bugs>
+ <fixes bugid="30573"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Ordered range scan over partitioned tables returns some
+ rows twice
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The issue appears to occur with a query using BETWEEN in the
+ WHERE clause and a GROUP BY on a different column on a table
+ with more than 20 partitions. Further analysis pending.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Partition"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30583"/>
</bugs>
@@ -1286,6 +2447,43 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: Partition"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30822"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>ALTER TABLE COALESCE PARTITION</literal>
+ causes segmentation fault
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The cause of this issue has been identified in the server
+ code.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: Privileges"/>
</tags>
@@ -1363,10 +2561,555 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27779"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Slave cannot read old rows log events.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A slave running MySQL 5.1.19 or newer cannot read logs
+ generated by a master running MySQL 5.1.18 or earlier. This
+ issue was apparently introduced by the fix for Bug #22583 in
+ MySQL 5.1.18. Work is in progress on a lasting solution for
+ this issue.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29020"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Event results not correctly replicated to slave in
+ <literal>RBR</literal>
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When an event has a short schedule (such as EVERY 1
+ SECONDS), it can sometimes happen that the event executes on
+ the master but its effects are not propagated to the slave.
+ The fix for this issue depends on the fix for Bug #12713,
+ which is expected in 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29549"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Endians: rpl_ndb_myisam2ndb,rpl_ndb_innodb2ndb and
+ rpl_ndb_mix_innodb failed on
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Row-based logging writes rows incorrectly on big-endian
+ machines where the storage engine sets the low byte first on
+ big-endian machines, while little-endian machines write the
+ fields in correct order. (The only known storage engine that
+ does this is NDB.) In effect, this means that row-based
+ replication from or to a big-endian machine where the table
+ uses NDB as storage engine fails if the other engine is
+ either non-NDB or on a little-endian machine. A fix for this
+ issue has been committed to 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: Replication"/>
</tags>
<bugs>
+ <fixes bugid="23333"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: stored function + non-transac table + transac table =
+ breaks stmt-based binlog
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ An UPDATE statement setting a column of a non-transactional
+ table to the value returned by a stored function that
+ modifies is not logged if it fails, whereas any query that
+ modifies a non-deterministic table should be logged even if
+ there is an error in the execution. Otherwise, the master
+ has a row in the non-transactional table that the slave does
+ not have. A fix for this issue is pending; it is expected to
+ appear in 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26000"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.0+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>SHOW SLAVE STATUS</literal> can crash mysqld
+ during shutdown process
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The sequence of events necessary to trigger this issue is
+ unlikely to occur during normal manual operation, but may
+ affect monitoring tools that execute SHOW SLAVE STATUS
+ automatically. A fix has been done for this issue in 5.0 and
+ is expected to be made to 5.1 in time for the 5.1-GA
+ release.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26199"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Replication of stored procedures with
+ <literal>BIT</literal> parameters fails
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The workaround is to use parameters of INT types rather than
+ BIT type.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26395"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: if crash during autocommit update to transactional
+ table on master, slave fails
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When a statement modifies an innodb table in autocommit
+ mode, and the master crashes afterwards, but before writing
+ the corresponding log event to disk, then the binlog may
+ contain only the INSERT. In such a case, when the master
+ restarts, InnoDB will roll back. The slave replicates the
+ INSERT but not the ROLLBACK, and so the result is that on
+ master the statement has been rolled back while on slave it
+ is executed. This does not occur with AUTOCOMMIT turned off,
+ since explicit BEGIN, COMMIT, and ROLLBACK statements are
+ generated and logged. A fix is in progress, but it is not
+ known at this whether it will be ready to appear in 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27808"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="6.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Infinite looping in circular replication
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This issue is known to arise in two different situations:
+ (1) if a server fails in circular replication and the user
+ fails over the replication; (2) when replicating a MySQL
+ Cluster, an event is created on a cluster SQL node and the
+ event is later received by a different SQL node in the same
+ cluster.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28086"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: <literal>SBR</literal> of <literal>USER</literal>()
+ becomes corrupted on slave
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Workaround: Use row-based rather than statement-based
+ replication of USER().
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28597"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.0+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Replication doesn't start after upgrading to 5.1.18
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This issue was encountered when upgrading the master and
+ slave from MySQL 5.1.16 to 5.1.18. A patch is pending and is
+ expected to be included in MySQL 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29288"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="6.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: myisam transactions replicated to a transactional slave
+ leaves slave unstable
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This issue is encountered if using transactions with MyISAM
+ and replicating to an InnoDB or NDB slave: the slave becomes
+ unstable. This is due to the commit not being recorded in
+ the binlog, so that the transactions are not completed on
+ the slave.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30209"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: rpl_packet.test: Slave_running mismatch (timing bug?)
+ </para>
+
+ <itemizedlist>
+
+ <listitem></listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30752"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.0+"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: rpl_dual_pos_advance valgrind (jump depends on
+ uninitialized <literal>LOG_INFO</literal>)
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ One thread in the MySQL replication code can read
+ uninitialized memory from the stack of another thread. This
+ appears to be strictly an internal issue; a fix has been
+ prepared and is expected to be committed to the server code
+ in time for MySQL 5.1.23 or 5.1.24.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30790"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Suspicious code in rpl_utility.cc
+ </para>
+
+ <itemizedlist>
+
+ <listitem></listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Replication"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30854"/>
</bugs>
@@ -1401,10 +3144,92 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
+ <manual type="Server: SP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="12713"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Error in a stored function called from a
+ <literal>SELECT</literal> doesn't cause
+ <literal>ROLLBACK</literal> of statem
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When AUTOCOMMIT=1, an error in a stored function called from
+ a SELECT statement fails to roll back the statement. This
+ can have consequences for row-based replication, such as the
+ problem with scheduled events encountered in Bug #29020. A
+ fix for this issue is expected in 5.1.23.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
<manual type="Server: Types"/>
</tags>
<bugs>
+ <fixes bugid="24541"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1"/>
+ <targetfix ver="6.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ %BUGID%: Sporadic "Data truncated..." warnings on decimal type
+ columns
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This is due to a problem uncovered in how MySQL peforms
+ conversions between decimal numbers and strings. A likely
+ solution has been found to this problem, but is not expected
+ to be applied until MySQL 5.2 due to the possibility of
+ users being adversely affected by unanticipated changes in
+ behaviour.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="custom" customname="open-bugs">
+
+ <tags>
+ <manual type="Server: Types"/>
+ </tags>
+
+ <bugs>
<fixes bugid="30587"/>
</bugs>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r8929 - trunk/dynamic-docs/open-bugs | mcbrown | 28 Nov |
