Author: mysqldocauto
Date: 2007-10-25 10:39:40 +0200 (Thu, 25 Oct 2007)
New Revision: 8312
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-10-25 01:49:02 UTC (rev 8311)
+++ trunk/dynamic-docs/open-bugs/mysqld.xml 2007-10-25 08:39:40 UTC (rev 8312)
Changed blocks: 20, Lines Added: 34, Lines Deleted: 692; 18922 bytes
@@ -45,45 +45,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="C API"/>
- </tags>
-
- <bugs>
- <fixes bugid="30472"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: libmysql doesn't reset charset, insert_id after succ.
- mysql_change_user() call
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- After mysql_change_user(), the character set variables
- should be just as after mysql_real_connect(). However, the
- server sets them to the global defaults. A workaround would
- be to explicitly reinitialize character set information
- explicitly following mysql_change_user().
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
<manual type="Client"/>
</tags>
@@ -285,48 +246,6 @@
</tags>
<bugs>
- <fixes bugid="21704"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Renaming column does not update <literal>FK</literal>
- definition
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Renaming a column that appears in a foreign key definition
- does not update the foreign key definition with the new
- column name; this occurs with both referenced and
- referencing tables. This could interefere with reloading
- from a dump, due to creating constraints against
- non-existent columns. Workaround: Drop and re-create
- manually any foreign key definitions affected by the
- renaming of a column.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server"/>
- </tags>
-
- <bugs>
<fixes bugid="22351"/>
</bugs>
@@ -1253,6 +1172,9 @@
using the -export-dynamic option to ld(1) for symbols
defined in the executable to become visible to dlsym().
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -1299,163 +1221,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="Server: DDL"/>
- </tags>
-
- <bugs>
- <fixes bugid="17565"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: <literal>RENAME DATABASE</literal> destroys events
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- RENAME DATABASE was intended only for updating names of
- pre-5.1 databases to the new 5.1 identifier encoding. It's
- being removed and replaced with ALTER TABLE db_name UPGRADE
- DATA DIRECTORY NAME.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: DDL"/>
- </tags>
-
- <bugs>
- <fixes bugid="28360"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: <literal>RENAME DATABASE</literal> destroys routines
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- RENAME DATABASE was intended only for updating names of
- pre-5.1 databases to the new 5.1 identifier encoding. It is
- being removed and replaced with ALTER TABLE db_name UPGRADE
- DATA DIRECTORY NAME.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: DML"/>
- </tags>
-
- <bugs>
- <fixes bugid="27358"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: <literal>INSERT DELAYED</literal> does not honour
- <literal>SQL_MODE</literal> of the client
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The SQL_MODE setting is ignored when a client issues INSERT
- DELAYED. A patch for this bug has been approved for MySQL
- 5.0, and is expected to be committed to 5.1 in the near
- future.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: Events"/>
- </tags>
-
- <bugs>
- <fixes bugid="31111"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: --read-only crashes MySQL (events fail to load)
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- --read-only caused the Event Manager to fail and crash the
- server at startup. Workaround: Do not use --read-only, or
- disable the Event Manager with --event-scheduler=0.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
<manual type="Server: Federated"/>
</tags>
@@ -1482,6 +1247,9 @@
SERVER specification as used by the Federated storage engine
causes the server to crash.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -1722,78 +1490,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="Server: General"/>
- </tags>
-
- <bugs>
- <fixes bugid="31048"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: many nested subqueries causes out of memory and crash
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- A query with deeply-nested subqueries causes runaway
- resource allocation, possibly resulting in a crash upon
- exhaustion of RAM. No workaround; anyone who can issue a
- query can cause it. DoS candidate.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: General"/>
- </tags>
-
- <bugs>
- <fixes bugid="31081"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: server crash in regexp function
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Using REGEX with ucs2 strings could cause a server crash.
- Workaround: Use an 8-bit character set if possible.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
<manual type="Server: InnoDB"/>
</tags>
@@ -2391,48 +2087,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="Server: Optimizer"/>
- </tags>
-
- <bugs>
- <fixes bugid="31094"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Forcing index-based sort doesn't work anymore if joins
- are done
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- A new optimizer rule was introduced in 5.1 to prefer
- filesort over indexed ORDER BY when accessing all rows of a
- table (because it is faster). However, the rule was being
- enforced even when a LIMIT clause was given, when the rule
- should not apply.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
<manual type="Server: Partition"/>
</tags>
@@ -2463,6 +2117,9 @@
table; the value is not truncated, and the statement does
not produce an error.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -2499,6 +2156,9 @@
WHERE clause and a GROUP BY on a different column on a table
with more than 20 partitions. Further analysis pending.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -2574,6 +2234,9 @@
The cause of this issue has been identified in the server
code.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -2625,91 +2288,6 @@
<logentry entrytype="custom" customname="open-bugs">
<tags>
- <manual type="Server: PS"/>
- </tags>
-
- <bugs>
- <fixes bugid="27430"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Crash in subquery code when in <literal>PS</literal>
- and table <literal>DDL</literal> changed after
- <literal>PREPARE</literal>
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Any user who is able to create/drop/alter tables may
- trivially crash the server daemon via the use of prepared
- statements. The only workaround to this possible DoS is to
- completely disallow prepared statements by setting the
- system variable max_prepared_stmt_count to 0.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 6.0
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: PS"/>
- </tags>
-
- <bugs>
- <fixes bugid="27690"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Re-execution of prepared statement after table was
- replaced with a view crashes
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Any user who is able to create/drop/alter tables may
- trivially crash the server daemon via the use of prepared
- statements. The only workaround to this possible DoS is to
- completely disallow prepared statements by setting the
- system variable max_prepared_stmt_count to 0.
- </para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 6.0
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
<manual type="Server: Query Cache"/>
</tags>
@@ -2750,78 +2328,6 @@
</tags>
<bugs>
- <fixes bugid="19958"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: rpl_trigger.test causes Error in Update_rows event when
- used with <literal>RBR</literal>
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: RBR"/>
- </tags>
-
- <bugs>
- <fixes bugid="26366"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: <literal>RBR</literal> fails with
- <literal>DELETE</literal> on concurrent locked InnoDB tables
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- When several sessions try simultaneously to access a locked
- InnoDB table, row-based replication fails following a DELETE
- FROM statement.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: RBR"/>
- </tags>
-
- <bugs>
<fixes bugid="27779"/>
</bugs>
@@ -2845,6 +2351,9 @@
MySQL 5.1.18. Work is in progress on a lasting solution for
this issue.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -2970,6 +2479,9 @@
table on the slave is created having extra columns as
compared to the same table on the master.
</para>
+ <para>
+ <emphasis role="bold">Target fix</emphasis>: 5.1
+ </para>
</listitem>
</itemizedlist>
@@ -2985,30 +2497,6 @@
</tags>
<bugs>
- <fixes bugid="21132"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Slave fails to reconnect on update_slave_list
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: Replication"/>
- </tags>
-
- <bugs>
<fixes bugid="23333"/>
</bugs>
@@ -3178,48 +2666,6 @@
</tags>
<bugs>
- <fixes bugid="26489"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Corruption in relay logs
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- This can occur whenusing unreliable connections between the
- master and slave. Suggested workarounds: (1) Use SSL
- connections to get an extra level of connection checking and
- possibly to prevent the issue from occurring; (2) if it does
- occur, use this sequence of stements to reset the slave:
- SHOW SLAVE STATUS; STOP SLAVE; CHANGE MASTER TO
- master_log_file=value_from_relay_master_log_file,
- master_log_pos=insert the value from Exec_master_log_pos;
- START SLAVE;.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: Replication"/>
- </tags>
-
- <bugs>
<fixes bugid="27808"/>
</bugs>
@@ -3344,45 +2790,9 @@
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="28618"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Skipping into the middle of a group with
- <literal>SQL_SLAVE_SKIP_COUNTER</literal> is possible
- </para>
-
- <itemizedlist>
-
- <listitem>
<para>
- A fix for this issue has been committed and is expected to
- be included in MySQL 5.1.23.
+ <emphasis role="bold">Target fix</emphasis>: 5.1
</para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
</listitem>
</itemizedlist>
@@ -3422,48 +2832,9 @@
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="29309"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: Incorrect "Seconds_Behind_Master" value in
- <literal>SHOW SLAVE STATUS</literal> after <literal>FLUSH
- LOGS</literal>
- </para>
-
- <itemizedlist>
-
- <listitem>
<para>
- When FLUSH TABLES is executed, there is a brief moment when
- the value of Seconds_Behind_Master is calculated
- incorrectly. This can cause false alerts for monitoring
- services.
+ <emphasis role="bold">Target fix</emphasis>: 6.0
</para>
- <para>
- <emphasis role="bold">Target fix</emphasis>: 5.1.23
- </para>
</listitem>
</itemizedlist>
@@ -3556,46 +2927,6 @@
</tags>
<bugs>
- <fixes bugid="29734"/>
- </bugs>
-
- <versions>
- <version ver="5.1"/>
- </versions>
-
- <message>
-
- <para>
- %BUGID%: thread_id=0 in binary log which leads to temporary
- table conflicts
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- In some cases, the binary log generated on the master can
- have thread_id=0, possibly for multiple threads. Normally,
- this does not matter; however, where two threads use the
- same temporary table, the pseudo_thread_id is also set to 0,
- and causing conflicts which interfere with replication and
- point-in-time recovery.
- </para>
- </listitem>
-
- </itemizedlist>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="custom" customname="open-bugs">
-
- <tags>
- <manual type="Server: Replication"/>
- </tags>
-
- <bugs>
<fixes bugid="30209"/>
</bugs>
@@ -3717,6 +3048,17 @@
vm-win2003-64-b
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This is probably a memory corruption issue. (The relevant
+ error code is <errorcode>ER_BAD_FIELD_ERROR</errorcode>.)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
</message>
</logentry>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r8312 - trunk/dynamic-docs/open-bugs | mysqldocauto | 25 Oct |
