Author: mcbrown
Date: 2007-11-28 08:33:41 +0100 (Wed, 28 Nov 2007)
New Revision: 8928
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 06:51:24 UTC (rev 8927)
+++ trunk/dynamic-docs/open-bugs/mysqld.xml 2007-11-28 07:33:41 UTC (rev 8928)
Changed blocks: 18, Lines Added: 0, Lines Deleted: 1906; 43184 bytes
@@ -9,46 +9,6 @@
</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>
@@ -85,206 +45,10 @@
<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>
@@ -324,38 +88,6 @@
</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>
@@ -397,45 +129,6 @@
</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>
@@ -476,42 +169,6 @@
</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>
@@ -584,85 +241,10 @@
<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>
@@ -852,125 +434,6 @@
</tags>
<bugs>
- <fixes bugid="24763"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- <targetfix ver="5.0"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Pointer too large: Please report a bug - Cluster -
- logs+traces included
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- So far, this issue has been encountered only in clusters
- having an odd number of data nodes per node group, which is
- not a recommended configuration. For best results, the
- number of data nodes should be equal to an even power of 2
- (2, 4, 8, ...) and NumberOfReplicas should be equal to 1 or
- 2.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: Cluster"/>
- </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>
@@ -1007,127 +470,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="Server: Cluster"/>
- </tags>
-
- <bugs>
- <fixes bugid="30407"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- <targetfix ver="5.0"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Lock Tables - Unlock Tables causes crash with
- <literal>NDBCLUSTER</literal> engine
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The issue occurs when performing a DELETE from an NDB table
- followed by an INSERT of a row whose primary key column
- value matches that of the deleted row while the table is
- write-locked with engine condition pushdown enabled. This
- issue is not known to occur prior to MySQL 5.0.42.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <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>
@@ -1172,41 +514,6 @@
</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>
@@ -1477,46 +784,6 @@
</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>
@@ -1593,44 +860,6 @@
</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>
@@ -1665,243 +894,10 @@
<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>
@@ -2016,164 +1012,6 @@
<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>
@@ -2336,48 +1174,6 @@
</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>
@@ -2417,44 +1213,6 @@
</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>
@@ -2528,43 +1286,6 @@
<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>
@@ -2642,555 +1363,10 @@
<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>
@@ -3225,92 +1401,10 @@
<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: r8928 - trunk/dynamic-docs/open-bugs | mcbrown | 28 Nov |
