From: Date: September 16 2008 9:00pm
Subject: svn commit - mysqldoc@docsrva: r11840 - in trunk: dynamic-docs/changelog refman-5.0 refman-5.1 refman-6.0
List-Archive: http://lists.mysql.com/commits/54229
Message-Id: <200809161900.m8GJ02il003174@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Author: jstephens
Date: 2008-09-16 21:00:01 +0200 (Tue, 16 Sep 2008)
New Revision: 11840
Log:
Updated changelog entry for Bug #23333; also added relevant info to
binary-log (Thanks, Todd!)
Modified:
trunk/dynamic-docs/changelog/mysqld.xml
trunk/refman-5.0/dba-core.xml
trunk/refman-5.1/dba-core.xml
trunk/refman-6.0/dba-core.xml
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 10, Lines Deleted: 0; 884 bytes
@@ -167,6 +167,16 @@
the master have a row that the copy on the slave did not.
+
+ In addition, when an INSERT ... ON DUPLICATE KEY
+ UPDATE statement encountered a duplicate key
+ constraint, but the UPDATE did not actually
+ change any data, the statement was not logged. As a result of
+ this fix, such statements are now treated the same for logging
+ purposes as other UPDATE statements, and so
+ are written to the binary log.
+
+
Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml 2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-5.0/dba-core.xml 2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 8; 2151 bytes
@@ -12607,14 +12607,25 @@
Updates to non-transactional tables are stored in the binary log
- immediately after execution. Within an uncommitted transaction,
- all updates (UPDATE,
- DELETE, or INSERT) that
- change transactional tables such as BDB or
- InnoDB tables are cached until a
- COMMIT statement is received by the server.
- At that point, mysqld writes the entire
- transaction to the binary log before the
+ immediately after execution. In MySQL 5.0.53 and earlier
+ versions of MySQL ¤t-series;, an UPDATE
+ statement using a stored function that modified a
+ non-transactional table was not logged if it failed, and an
+ INSERT ... ON DUPLICATE KEY UPDATE statement
+ that encountered a duplicate key constraint — but which
+ did not actually change any data — was not logged.
+ Beginning with MySQL 5.0.54, both of these statements are
+ written to the binary log. (Bug #23333)
+
+
+
+ Within an uncommitted transaction, all updates
+ (UPDATE, DELETE, or
+ INSERT) that change transactional tables such
+ as BDB or InnoDB tables
+ are cached until a COMMIT statement is
+ received by the server. At that point, mysqld
+ writes the entire transaction to the binary log before the
COMMIT is executed. When the thread that
handles the transaction starts, it allocates a buffer of
binlog_cache_size to buffer statements. If a
Modified: trunk/refman-5.1/dba-core.xml
===================================================================
--- trunk/refman-5.1/dba-core.xml 2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-5.1/dba-core.xml 2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 17, Lines Deleted: 5; 1840 bytes
@@ -13668,11 +13668,23 @@
Updates to non-transactional tables are stored in the binary log
- immediately after execution. Within an uncommitted transaction,
- all updates (UPDATE,
- DELETE, or INSERT) that
- change transactional tables such as InnoDB
- tables are cached until a COMMIT statement is
+ immediately after execution. In MySQL 5.1.22 and earlier
+ versions of MySQL ¤t-series;, an UPDATE
+ statement using a stored function that modified a
+ non-transactional table was not logged if it failed, and an
+ INSERT ... ON DUPLICATE KEY UPDATE statement
+ that encountered a duplicate key constraint — but which
+ did not actually change any data — was not logged.
+ Beginning with MySQL 5.1.23, both of these statements are
+ written to the binary log. (Bug #23333)
+
+
+
+ Within an uncommitted transaction, all updates
+ (UPDATE, DELETE, or
+ INSERT) that change transactional tables such
+ as BDB or InnoDB tables
+ are cached until a COMMIT statement is
received by the server. At that point, mysqld
writes the entire transaction to the binary log before the
COMMIT is executed. When the thread that
Modified: trunk/refman-6.0/dba-core.xml
===================================================================
--- trunk/refman-6.0/dba-core.xml 2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-6.0/dba-core.xml 2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 17, Lines Deleted: 5; 1838 bytes
@@ -13607,11 +13607,23 @@
Updates to non-transactional tables are stored in the binary log
- immediately after execution. Within an uncommitted transaction,
- all updates (UPDATE,
- DELETE, or INSERT) that
- change transactional tables such as InnoDB
- tables are cached until a COMMIT statement is
+ immediately after execution. In MySQL 6.0.3 and earlier versions
+ of MySQL ¤t-series;, an UPDATE
+ statement using a stored function that modified a
+ non-transactional table was not logged if it failed, and an
+ INSERT ... ON DUPLICATE KEY UPDATE statement
+ that encountered a duplicate key constraint — but which
+ did not actually change any data — was not logged.
+ Beginning with MySQL 6.0.4, both of these statements are written
+ to the binary log. (Bug #23333)
+
+
+
+ Within an uncommitted transaction, all updates
+ (UPDATE, DELETE, or
+ INSERT) that change transactional tables such
+ as BDB or InnoDB tables
+ are cached until a COMMIT statement is
received by the server. At that point, mysqld
writes the entire transaction to the binary log before the
COMMIT is executed. When the thread that