Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3562 05/09/14 13:01:26 paul@stripped +8 -0
Warn against mixing engines within transactions.
refman/storage-engines.xml
1.26 05/09/14 13:01:25 paul@stripped +10 -3
Warn against mixing engines within transactions.
refman/sql-syntax.xml
1.71 05/09/14 13:01:25 paul@stripped +40 -15
Warn against mixing engines within transactions.
refman-5.1/storage-engines.xml
1.19 05/09/14 13:01:25 paul@stripped +10 -3
Sync.
refman-5.1/sql-syntax.xml
1.45 05/09/14 13:01:25 paul@stripped +40 -15
Sync.
refman-5.0/storage-engines.xml
1.19 05/09/14 13:01:25 paul@stripped +10 -3
Sync.
refman-5.0/sql-syntax.xml
1.46 05/09/14 13:01:25 paul@stripped +40 -15
Sync.
refman-4.1/storage-engines.xml
1.27 05/09/14 13:01:25 paul@stripped +10 -3
Sync.
refman-4.1/sql-syntax.xml
1.62 05/09/14 13:01:25 paul@stripped +65 -35
Sync.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: kite-hub.kitebird.com
# Root: /src/extern/MySQL/bk/mysqldoc
--- 1.44/refman-5.1/sql-syntax.xml 2005-09-14 10:24:07 -05:00
+++ 1.45/refman-5.1/sql-syntax.xml 2005-09-14 13:01:25 -05:00
@@ -10211,18 +10211,43 @@
</para>
<para>
- Note that if you are not using transaction-safe tables, any
- changes are stored at once, regardless of the status of
- autocommit mode.
+ For best results, transactions should be performed using only
+ tables managed by a single transactional storage engine.
+ Otherwise, the following problems can occur:
</para>
- <para>
- If you issue a <literal>ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
- <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
- occurs. Changes to transaction-safe tables are rolled back, but
- not changes to non-transaction-safe tables.
- </para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If you use tables from more than one transaction-safe
+ storage engine (such as <literal>InnoDB</literal> and
+ <literal>BDB</literal>), it is possible that when one
+ transaction commits, another ongoing transaction that uses
+ the same tables will see only some of the changes made by
+ the first transaction. That is, the atomicity of
+ transactions is not guaranteed with mixed engines and
+ inconsistencies can result.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use non-transaction-safe tables within a transaction,
+ any changes are stored at once, regardless of the status of
+ autocommit mode.
+ </para>
+
+ <para>
+ If you issue a <literal>ROLLBACK</literal> statement after
+ updating a non-transactional table within a transaction, an
+ <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
+ occurs. Changes to transaction-safe tables are rolled back,
+ but not changes to non-transaction-safe tables.
+ </para>
+ </listitem>
+
+ </itemizedlist>
<para>
Each transaction is stored in the binary log in one chunk, upon
@@ -18879,12 +18904,12 @@
</para>
<para>
- Whether or not the I/O thread is started and has
- connected successfully to the master.
- For older versions of MySQL (prior to 4.1.14 and 5.0.12)
+ Whether or not the I/O thread is started and has connected
+ successfully to the master. For older versions of MySQL
+ (prior to 4.1.14 and 5.0.12)
<literal>Slave_IO_Running</literal> will be set to
- <literal>YES</literal> if the I/O thread is started,
- even if the slave hasn't connected to the master yet.
+ <literal>YES</literal> if the I/O thread is started, even
+ if the slave hasn't connected to the master yet.
</para>
</listitem>
--- 1.18/refman-5.1/storage-engines.xml 2005-09-10 18:54:02 -05:00
+++ 1.19/refman-5.1/storage-engines.xml 2005-09-14 13:01:25 -05:00
@@ -356,9 +356,9 @@
<listitem>
<para>
- Safer. Even if MySQL crashes or you get hardware problems, you
- can get your data back, either by automatic recovery or from a
- backup plus the transaction log.
+ They are safer. Even if MySQL crashes or you get hardware
+ problems, you can get your data back, either by automatic
+ recovery or from a backup plus the transaction log.
</para>
</listitem>
@@ -393,6 +393,13 @@
</listitem>
</itemizedlist>
+
+ <para>
+ Although MySQL supports several transaction-safe storage engines,
+ for best results, you should not mix different table types within a
+ transaction. For information about the problems that can occur if
+ you do this, see <xref linkend="commit"/>.
+ </para>
<para>
In MySQL ¤t-series;, <literal>InnoDB</literal> uses default
--- 1.61/refman-4.1/sql-syntax.xml 2005-09-14 09:57:55 -05:00
+++ 1.62/refman-4.1/sql-syntax.xml 2005-09-14 13:01:25 -05:00
@@ -9337,18 +9337,43 @@
</para>
<para>
- Note that if you are not using transaction-safe tables, any
- changes are stored at once, regardless of the status of
- autocommit mode.
+ For best results, transactions should be performed using only
+ tables managed by a single transactional storage engine.
+ Otherwise, the following problems can occur:
</para>
- <para>
- If you issue a <literal>ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
- <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
- occurs. Changes to transaction-safe tables are rolled back, but
- not changes to non-transaction-safe tables.
- </para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If you use tables from more than one transaction-safe
+ storage engine (such as <literal>InnoDB</literal> and
+ <literal>BDB</literal>), it is possible that when one
+ transaction commits, another ongoing transaction that uses
+ the same tables will see only some of the changes made by
+ the first transaction. That is, the atomicity of
+ transactions is not guaranteed with mixed engines and
+ inconsistencies can result.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use non-transaction-safe tables within a transaction,
+ any changes are stored at once, regardless of the status of
+ autocommit mode.
+ </para>
+
+ <para>
+ If you issue a <literal>ROLLBACK</literal> statement after
+ updating a non-transactional table within a transaction, an
+ <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
+ occurs. Changes to transaction-safe tables are rolled back,
+ but not changes to non-transaction-safe tables.
+ </para>
+ </listitem>
+
+ </itemizedlist>
<para>
If you are using <literal>START TRANSACTION</literal> or
@@ -12564,36 +12589,41 @@
<para>
<literal>ONE_SHOT</literal>
</para>
+
<para>
- This is not a server system variable, but it can be used
- to influence the effect of variables that set the character
+ This is not a server system variable, but it can be used to
+ influence the effect of variables that set the character
set, the collation, and the time zone.
- <literal>ONE_SHOT</literal> is primarily used for
- replication purposes: <command>mysqlbinlog</command> uses
- <literal>SET ONE_SHOT</literal> to temporarily modify the
- values of character set, collation, and timezone variables
+ <literal>ONE_SHOT</literal> is primarily used for
+ replication purposes: <command>mysqlbinlog</command> uses
+ <literal>SET ONE_SHOT</literal> to temporarily modify the
+ values of character set, collation, and timezone variables
to reflect at rollforward what they were originally.
- <literal>ONE_SHOT</literal> is available as of MySQL
- 4.1.3 and 5.0.
+ <literal>ONE_SHOT</literal> is available as of MySQL 4.1.3
+ and 5.0.
</para>
+
<para>
You cannot use <literal>ONE_SHOT</literal> with other than
the allowed set of variables; if you try, you get an error
like this:
+
<programlisting>
mysql> <userinput>SET ONE_SHOT max_allowed_packet = 1;</userinput>
ERROR 1382 (HY000): The 'SET ONE_SHOT' syntax is reserved for purposes internal to the MySQL server
</programlisting>
</para>
+
<para>
- If <literal>ONE_SHOT</literal> is used with the allowed
+ If <literal>ONE_SHOT</literal> is used with the allowed
variables, it changes the variables as requested, but
resets, after the next statement, all character set,
collation, and time zone-related server system variables.
- The only exception when resetting doesn't happen is when
- the next statement is a <literal>SET</literal> statement.
- In other words, resetting takes place after the next
+ The only exception when resetting doesn't happen is when the
+ next statement is a <literal>SET</literal> statement. In
+ other words, resetting takes place after the next
non-<literal>SET</literal> statement. Example:
+
<programlisting>
mysql> <userinput>SET ONE_SHOT character_set_connection = latin5;</userinput>
@@ -16925,14 +16955,14 @@
listed in
<xref linkend="replication-implementation-details"/>.
Looking at this field is necessary for older versions of
- MySQL (prior to 4.1.14 and 5.0.12) because in these
- versions the thread could be running while unsuccessfully
- trying to connect to the master; only this field makes you
- aware of the connection problem. The state of the SQL
- thread is not copied because it is simpler. If it is
- running, there is no problem; if it is not, you can find
- the error in the
- <literal>Last_Error</literal> field (described below).
+ MySQL (prior to 4.1.14 and 5.0.12) because in these
+ versions the thread could be running while unsuccessfully
+ trying to connect to the master; only this field makes you
+ aware of the connection problem. The state of the SQL
+ thread is not copied because it is simpler. If it is
+ running, there is no problem; if it is not, you can find
+ the error in the <literal>Last_Error</literal> field
+ (described below).
</para>
<para>
@@ -17042,12 +17072,12 @@
</para>
<para>
- Whether or not the I/O thread is started and has
- connected successfully to the master.
- For older versions of MySQL (prior to 4.1.14 and 5.0.12)
+ Whether or not the I/O thread is started and has connected
+ successfully to the master. For older versions of MySQL
+ (prior to 4.1.14 and 5.0.12)
<literal>Slave_IO_Running</literal> will be set to
- <literal>YES</literal> if the I/O thread is started,
- even if the slave hasn't connected to the master yet.
+ <literal>YES</literal> if the I/O thread is started, even
+ if the slave hasn't connected to the master yet.
</para>
</listitem>
--- 1.26/refman-4.1/storage-engines.xml 2005-09-10 18:53:57 -05:00
+++ 1.27/refman-4.1/storage-engines.xml 2005-09-14 13:01:25 -05:00
@@ -339,9 +339,9 @@
<listitem>
<para>
- Safer. Even if MySQL crashes or you get hardware problems, you
- can get your data back, either by automatic recovery or from a
- backup plus the transaction log.
+ They are safer. Even if MySQL crashes or you get hardware
+ problems, you can get your data back, either by automatic
+ recovery or from a backup plus the transaction log.
</para>
</listitem>
@@ -376,6 +376,13 @@
</listitem>
</itemizedlist>
+
+ <para>
+ Although MySQL supports several transaction-safe storage engines,
+ for best results, you should not mix different table types within a
+ transaction. For information about the problems that can occur if
+ you do this, see <xref linkend="commit"/>.
+ </para>
<para>
Note that to use the <literal>InnoDB</literal> storage engine in
--- 1.70/refman/sql-syntax.xml 2005-09-14 10:24:06 -05:00
+++ 1.71/refman/sql-syntax.xml 2005-09-14 13:01:25 -05:00
@@ -9581,18 +9581,43 @@
</para>
<para>
- Note that if you are not using transaction-safe tables, any
- changes are stored at once, regardless of the status of
- autocommit mode.
+ For best results, transactions should be performed using only
+ tables managed by a single transactional storage engine.
+ Otherwise, the following problems can occur:
</para>
- <para>
- If you issue a <literal>ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
- <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
- occurs. Changes to transaction-safe tables are rolled back, but
- not changes to non-transaction-safe tables.
- </para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If you use tables from more than one transaction-safe
+ storage engine (such as <literal>InnoDB</literal> and
+ <literal>BDB</literal>), it is possible that when one
+ transaction commits, another ongoing transaction that uses
+ the same tables will see only some of the changes made by
+ the first transaction. That is, the atomicity of
+ transactions is not guaranteed with mixed engines and
+ inconsistencies can result.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use non-transaction-safe tables within a transaction,
+ any changes are stored at once, regardless of the status of
+ autocommit mode.
+ </para>
+
+ <para>
+ If you issue a <literal>ROLLBACK</literal> statement after
+ updating a non-transactional table within a transaction, an
+ <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
+ occurs. Changes to transaction-safe tables are rolled back,
+ but not changes to non-transaction-safe tables.
+ </para>
+ </listitem>
+
+ </itemizedlist>
<para>
If you are using <literal>START TRANSACTION</literal> or
@@ -18077,12 +18102,12 @@
</para>
<para>
- Whether or not the I/O thread is started and has
- connected successfully to the master.
- For older versions of MySQL (prior to 4.1.14 and 5.0.12)
+ Whether or not the I/O thread is started and has connected
+ successfully to the master. For older versions of MySQL
+ (prior to 4.1.14 and 5.0.12)
<literal>Slave_IO_Running</literal> will be set to
- <literal>YES</literal> if the I/O thread is started,
- even if the slave hasn't connected to the master yet.
+ <literal>YES</literal> if the I/O thread is started, even
+ if the slave hasn't connected to the master yet.
</para>
</listitem>
--- 1.25/refman/storage-engines.xml 2005-09-10 18:54:08 -05:00
+++ 1.26/refman/storage-engines.xml 2005-09-14 13:01:25 -05:00
@@ -354,9 +354,9 @@
<listitem>
<para>
- Safer. Even if MySQL crashes or you get hardware problems, you
- can get your data back, either by automatic recovery or from a
- backup plus the transaction log.
+ They are safer. Even if MySQL crashes or you get hardware
+ problems, you can get your data back, either by automatic
+ recovery or from a backup plus the transaction log.
</para>
</listitem>
@@ -391,6 +391,13 @@
</listitem>
</itemizedlist>
+
+ <para>
+ Although MySQL supports several transaction-safe storage engines,
+ for best results, you should not mix different table types within a
+ transaction. For information about the problems that can occur if
+ you do this, see <xref linkend="commit"/>.
+ </para>
<para>
Note that to use the <literal>InnoDB</literal> storage engine in
--- 1.45/refman-5.0/sql-syntax.xml 2005-09-14 10:24:06 -05:00
+++ 1.46/refman-5.0/sql-syntax.xml 2005-09-14 13:01:25 -05:00
@@ -9472,18 +9472,43 @@
</para>
<para>
- Note that if you are not using transaction-safe tables, any
- changes are stored at once, regardless of the status of
- autocommit mode.
+ For best results, transactions should be performed using only
+ tables managed by a single transactional storage engine.
+ Otherwise, the following problems can occur:
</para>
- <para>
- If you issue a <literal>ROLLBACK</literal> statement after
- updating a non-transactional table within a transaction, an
- <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
- occurs. Changes to transaction-safe tables are rolled back, but
- not changes to non-transaction-safe tables.
- </para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If you use tables from more than one transaction-safe
+ storage engine (such as <literal>InnoDB</literal> and
+ <literal>BDB</literal>), it is possible that when one
+ transaction commits, another ongoing transaction that uses
+ the same tables will see only some of the changes made by
+ the first transaction. That is, the atomicity of
+ transactions is not guaranteed with mixed engines and
+ inconsistencies can result.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use non-transaction-safe tables within a transaction,
+ any changes are stored at once, regardless of the status of
+ autocommit mode.
+ </para>
+
+ <para>
+ If you issue a <literal>ROLLBACK</literal> statement after
+ updating a non-transactional table within a transaction, an
+ <literal>ER_WARNING_NOT_COMPLETE_ROLLBACK</literal> warning
+ occurs. Changes to transaction-safe tables are rolled back,
+ but not changes to non-transaction-safe tables.
+ </para>
+ </listitem>
+
+ </itemizedlist>
<para>
Each transaction is stored in the binary log in one chunk, upon
@@ -18155,12 +18180,12 @@
</para>
<para>
- Whether or not the I/O thread is started and has
- connected successfully to the master.
- For older versions of MySQL (prior to 4.1.14 and 5.0.12)
+ Whether or not the I/O thread is started and has connected
+ successfully to the master. For older versions of MySQL
+ (prior to 4.1.14 and 5.0.12)
<literal>Slave_IO_Running</literal> will be set to
- <literal>YES</literal> if the I/O thread is started,
- even if the slave hasn't connected to the master yet.
+ <literal>YES</literal> if the I/O thread is started, even
+ if the slave hasn't connected to the master yet.
</para>
</listitem>
--- 1.18/refman-5.0/storage-engines.xml 2005-09-10 18:54:00 -05:00
+++ 1.19/refman-5.0/storage-engines.xml 2005-09-14 13:01:25 -05:00
@@ -356,9 +356,9 @@
<listitem>
<para>
- Safer. Even if MySQL crashes or you get hardware problems, you
- can get your data back, either by automatic recovery or from a
- backup plus the transaction log.
+ They are safer. Even if MySQL crashes or you get hardware
+ problems, you can get your data back, either by automatic
+ recovery or from a backup plus the transaction log.
</para>
</listitem>
@@ -393,6 +393,13 @@
</listitem>
</itemizedlist>
+
+ <para>
+ Although MySQL supports several transaction-safe storage engines,
+ for best results, you should not mix different table types within a
+ transaction. For information about the problems that can occur if
+ you do this, see <xref linkend="commit"/>.
+ </para>
<para>
In MySQL ¤t-series;, <literal>InnoDB</literal> uses default
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (paul:1.3562) | paul | 14 Sep |
