Author: paul
Date: 2008-11-07 20:14:46 +0100 (Fri, 07 Nov 2008)
New Revision: 12337
Log:
r35421@frost: paul | 2008-11-07 12:59:14 -0500
Add auto-link markup
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/dynamic-docs/changelog/mysqld.xml
trunk/refman-4.1/dba-core.xml
trunk/refman-4.1/news-3.23.xml
trunk/refman-4.1/news-4.0.xml
trunk/refman-4.1/programs-client.xml
trunk/refman-4.1/replication.xml
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-4.1/sql-syntax-transactions.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/dba-core.xml
trunk/refman-5.0/programs-client-core.xml
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.0/se-bdb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.0/sql-syntax-transactions.xml
trunk/refman-5.0/stored-programs-views.xml
trunk/refman-5.1/dba-core.xml
trunk/refman-5.1/programs-client-core.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-5.1/sql-syntax-transactions.xml
trunk/refman-5.1/stored-programs-views.xml
trunk/refman-6.0/dba-core.xml
trunk/refman-6.0/programs-client-core.xml
trunk/refman-6.0/replication-notes.xml
trunk/refman-6.0/se-innodb-core.xml
trunk/refman-6.0/sql-syntax-transactions.xml
trunk/refman-6.0/stored-programs-views.xml
trunk/refman-common/news-innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35420
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35421
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 25, Lines Added: 88, Lines Deleted: 62; 15360 bytes
@@ -397,12 +397,12 @@
A duplicate key error raised when inserting into an
<literal>NDBCLUSTER</literal> table caused the current
transaction to abort, after which any SQL statement other than a
- <literal role="stmt" condition="commit">ROLLBACK</literal> failed. With this fix, the
- <literal>NDBCLUSTER</literal> storage engine now supports
- rollback of individual statements in such cases, and it is no
- longer necessary to issue an explicit
- <literal role="stmt" condition="commit">ROLLBACK</literal> and then retry the entire
- transaction.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ failed. With this fix, the <literal>NDBCLUSTER</literal> storage
+ engine now supports rollback of individual statements in such
+ cases, and it is no longer necessary to issue an explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal> and
+ then retry the entire transaction.
</para>
</message>
@@ -1936,7 +1936,8 @@
<para>
It was not possible to set the value of
<literal>falcon_consistent_read</literal> within the local
- scope. You can now set the global value, using <literal role="stmt" condition="set-option">SET
+ scope. You can now set the global value, using
+ <literal role="stmt" condition="set-option">SET
GLOBAL</literal>, but this affects only the current local scope
and all new connections made after the global variable was set.
</para>
@@ -6386,10 +6387,10 @@
<message>
<para>
- Executing a <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> statement after
- creating a temporary table in the <literal>mysql</literal>
- database with the same name as one of the MySQL system tables
- caused the server to crash.
+ Executing a <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> statement after creating a temporary table
+ in the <literal>mysql</literal> database with the same name as
+ one of the MySQL system tables caused the server to crash.
<note>
<para>
While it is possible to shadow a system table in this way,
@@ -7149,7 +7150,8 @@
<para>
It was possible to exhaust memory by repeatedly running
<literal>index_merge</literal> queries and never performing any
- <literal role="stmt" condition="flush">FLUSH TABLES</literal> statements.
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ statements.
</para>
</message>
@@ -7837,9 +7839,10 @@
<message>
<para>
- An extraneous <literal role="stmt" condition="commit">ROLLBACK</literal> statement was written
- to the binary log by a connection that did not use any
- transactional tables.
+ An extraneous
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement was written to the binary log by a connection that did
+ not use any transactional tables.
</para>
</message>
@@ -9298,10 +9301,11 @@
If a <literal role="stmt">SELECT</literal> calls a stored
function in a transaction, and a statement within the function
fails, that statement should roll back. Furthermore, if
- <literal role="stmt" condition="commit">ROLLBACK</literal> is executed after that, the entire
- transaction should be rolled back. Before this fix, the failed
- statement did not roll back when it failed (even though it might
- ultimately get rolled back by a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ <literal role="stmt" condition="commit">ROLLBACK</literal> is
+ executed after that, the entire transaction should be rolled
+ back. Before this fix, the failed statement did not roll back
+ when it failed (even though it might ultimately get rolled back
+ by a <literal role="stmt" condition="commit">ROLLBACK</literal>
later that rolls back the entire transaction).
</para>
@@ -10269,7 +10273,8 @@
table while in <literal>AUTOCOMMIT</literal> mode, the slave
failed. This fix causes every transaction (including
<literal>AUTOCOMMIT</literal> transactions) to be recorded in
- the binlog as starting with a <literal>BEGIN</literal> and
+ the binlog as starting with a
+ <literal role="stmt" condition="commit">BEGIN</literal> and
ending with a <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -14101,7 +14106,8 @@
<listitem>
<para>
- Bug #26379 - Combination of <literal role="stmt" condition="flush">FLUSH TABLE</literal>
+ Bug #26379 - Combination of
+ <literal role="stmt" condition="flush">FLUSH TABLE</literal>
and <literal role="stmt">REPAIR TABLE</literal> corrupts a
<literal>MERGE</literal> table. This was caused in a number
of situations:
@@ -14134,14 +14140,16 @@
<listitem>
<para>
- Two <literal role="stmt" condition="flush">FLUSH TABLES</literal> within a
- <literal role="stmt">LOCK TABLES</literal> segment can
- invalidate the lock. This does not require a
- <literal>MERGE</literal> table. The first <literal role="stmt" condition="flush">FLUSH
+ Two <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> within a <literal role="stmt">LOCK
+ TABLES</literal> segment can invalidate the lock. This
+ does not require a <literal>MERGE</literal> table. The
+ first <literal role="stmt" condition="flush">FLUSH
TABLES</literal> can be replaced by any statement that
requires other threads to reopen the table. In 5.0 and
- 5.1 a single <literal role="stmt" condition="flush">FLUSH TABLES</literal> can provoke
- the problem.
+ 5.1 a single
+ <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> can provoke the problem.
</para>
</listitem>
@@ -14200,7 +14208,8 @@
<listitem>
<para>
- Bug #30275 - <literal>MERGE</literal> tables: <literal role="stmt" condition="flush">FLUSH
+ Bug #30275 - <literal>MERGE</literal> tables:
+ <literal role="stmt" condition="flush">FLUSH
TABLES</literal> or
<literal role="stmt" condition="lock-tables">UNLOCK
TABLES</literal> causes server to crash.
@@ -15250,9 +15259,9 @@
<message>
<para>
- Sending several <literal role="stmt" condition="kill">KILL QUERY</literal> statements to
- target a connection running <literal>SELECT SLEEP()</literal>
- could freeze the server.
+ Sending several <literal role="stmt" condition="kill">KILL
+ QUERY</literal> statements to target a connection running
+ <literal>SELECT SLEEP()</literal> could freeze the server.
</para>
</message>
@@ -15279,9 +15288,10 @@
<message>
<para>
- For <literal role="stmt" condition="flush">FLUSH TABLES WITH READ LOCK</literal>, the server
- failed to properly detect write-locked tables when running with
- low-priority updates, resulting in a crash or deadlock.
+ For <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ READ LOCK</literal>, the server failed to properly detect
+ write-locked tables when running with low-priority updates,
+ resulting in a crash or deadlock.
</para>
</message>
@@ -16051,8 +16061,9 @@
<message>
<para>
- If a global read lock acquired with <literal role="stmt" condition="flush">FLUSH TABLES WITH
- READ LOCK</literal> was in effect, executing
+ If a global read lock acquired with
+ <literal role="stmt" condition="flush">FLUSH TABLES WITH READ
+ LOCK</literal> was in effect, executing
<literal role="stmt">ALTER TABLE</literal> could cause a server
crash.
</para>
@@ -16083,7 +16094,8 @@
<para>
For a table that had been opened with
<literal role="stmt">HANDLER</literal> and marked for reopening
- after being closed with <literal role="stmt" condition="flush">FLUSH TABLES</literal>,
+ after being closed with
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>,
<literal role="stmt">DROP TABLE</literal> did not properly
discard the handler.
</para>
@@ -18443,10 +18455,12 @@
<message>
<para>
- The <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB STATUS</literal> and
- <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB MUTEX</literal> statements
- incorrectly required the <literal>SUPER</literal> privilege
- rather than the <literal>PROCESS</literal> privilege.
+ The <literal role="stmt" condition="show-engine">SHOW ENGINE
+ INNODB STATUS</literal> and
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ MUTEX</literal> statements incorrectly required the
+ <literal>SUPER</literal> privilege rather than the
+ <literal>PROCESS</literal> privilege.
</para>
</message>
@@ -21496,7 +21510,8 @@
<para>
Enabling the <literal>PAD_CHAR_TO_FULL_LENGTH</literal> SQL mode
- caused privilege-loading operations (such as <literal role="stmt" condition="flush">FLUSH
+ caused privilege-loading operations (such as
+ <literal role="stmt" condition="flush">FLUSH
PRIVILEGES</literal>) to include trailing spaces from grant
table values stored in <literal role="type">CHAR</literal>
columns. Authentication for incoming connections failed as a
@@ -22827,9 +22842,11 @@
<message>
<para>
- Concurrent execution of <literal role="stmt" condition="flush">FLUSH TABLES</literal> along
- with <literal>SHOW FUNCTION STATUS</literal> or <literal>SHOW
- PROCEDURE STATUS</literal> could cause a server crash.
+ Concurrent execution of
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ along with <literal>SHOW FUNCTION STATUS</literal> or
+ <literal>SHOW PROCEDURE STATUS</literal> could cause a server
+ crash.
</para>
</message>
@@ -22985,8 +23002,9 @@
memory cached for server structures created by
<literal role="stmt">CREATE SERVER</literal>, so repeated
iterations of these statements resulted in a memory leak.
- <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> now releases the memory
- allocated for <literal role="stmt">CREATE SERVER</literal>.
+ <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> now releases the memory allocated for
+ <literal role="stmt">CREATE SERVER</literal>.
</para>
</message>
@@ -25480,7 +25498,8 @@
<para>
A change has been made to the way that the server handles
prepared statements. This affects prepared statements processed
- at the SQL level (using the <literal role="stmt" condition="sql-syntax-prepared-statements">PREPARE</literal>
+ at the SQL level (using the
+ <literal role="stmt" condition="sql-syntax-prepared-statements">PREPARE</literal>
statement) and those processed using the binary client-server
protocol (using the
<literal role="cfunc">mysql_stmt_prepare()</literal> C API
@@ -26618,12 +26637,14 @@
<para>
<command>mysqldump</command> now adds the
- <literal>LOCAL</literal> qualifier to the <literal role="stmt" condition="flush">FLUSH
- TABLES</literal> statement that is sent to the server when the
+ <literal>LOCAL</literal> qualifier to the
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ statement that is sent to the server when the
<option>--master-data</option> option is enabled. This prevents
- the <literal role="stmt" condition="flush">FLUSH TABLES</literal> statement from replicating
- to slaves, which is disadvantageous because it would cause
- slaves to block while the statement executes.
+ the <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> statement from replicating to slaves, which is
+ disadvantageous because it would cause slaves to block while the
+ statement executes.
</para>
</message>
@@ -28024,8 +28045,9 @@
<message>
<para>
- The <literal role="stmt" condition="flush">FLUSH PRIVILEGES</literal> statement did not
- produce an error when it failed.
+ The <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> statement did not produce an error when it
+ failed.
</para>
</message>
@@ -28782,7 +28804,8 @@
<message>
<para>
- Some performance problems of <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ Some performance problems of
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
STATUS</literal> were reduced by removing <literal>used
cells</literal> and <literal>Total number of lock structs in row
lock hash table</literal> from the output. These values are now
@@ -30388,8 +30411,10 @@
<listitem>
<para>
- A new statement, <literal role="stmt" condition="flush">FLUSH BACKUP LOGS</literal>,
- closes and reopens the backup log files. A new option for
+ A new statement,
+ <literal role="stmt" condition="flush">FLUSH BACKUP
+ LOGS</literal>, closes and reopens the backup log files. A
+ new option for
<literal role="cfunc">mysql_refresh()</literal>,
<literal>REFRESH_BACKUP_LOG</literal>, performs the same
operation.
@@ -30649,9 +30674,9 @@
A server crash resulted from concurrent execution of a
multiple-table <literal role="stmt">UPDATE</literal> that used a
<literal>NATURAL</literal> or <literal>USING</literal> join
- together with <literal role="stmt" condition="flush">FLUSH TABLES WITH READ LOCK</literal> or
- <literal role="stmt">ALTER TABLE</literal> for the table being
- updated.
+ together with <literal role="stmt" condition="flush">FLUSH
+ TABLES WITH READ LOCK</literal> or <literal role="stmt">ALTER
+ TABLE</literal> for the table being updated.
</para>
</message>
@@ -30706,7 +30731,8 @@
<para>
A server crash resulted from execution of an
<literal role="stmt">UPDATE</literal> that used a derived table
- together with <literal role="stmt" condition="flush">FLUSH TABLES</literal>.
+ together with <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal>.
</para>
</message>
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 20, Lines Added: 65, Lines Deleted: 50; 11834 bytes
@@ -304,8 +304,10 @@
This fix improves on one made for this bug in MySQL 5.1.20; the
previous fix insured that the slave could not be made to jump
into the middle of an event group, but the slave failed to
- recognize that <literal>BEGIN</literal>,
- <literal role="stmt">COMMIT</literal>, and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ recognize that
+ <literal role="stmt" condition="commit">BEGIN</literal>,
+ <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statements could begin or end an event group.
</para>
@@ -2497,8 +2499,8 @@
<para>
Using <literal>SELECT ... FOR UPDATE</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> could cause
- <literal>mysqld</literal> to hang indefinitely.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> could
+ cause <literal>mysqld</literal> to hang indefinitely.
</para>
</message>
@@ -3559,9 +3561,9 @@
<message>
<para>
- Using <literal role="stmt" condition="commit">ROLLBACK</literal> after a
- <literal role="stmt">DELETE</literal> does not restore the
- deleted row.
+ Using <literal role="stmt" condition="commit">ROLLBACK</literal>
+ after a <literal role="stmt">DELETE</literal> does not restore
+ the deleted row.
</para>
</message>
@@ -12103,12 +12105,12 @@
1146 (42S02): Table 'db.tbl' doesn't exist</errortext>. However,
the actual reason that such a trigger fails is due to the fact
that <literal role="stmt">CREATE TABLE</literal> causes an
- implicit <literal role="stmt">COMMIT</literal>, and so a trigger cannot
- invoke a stored routine containing this statement. A trigger
- which does so now fails with <errortext>ERROR 1422 (HY000):
- Explicit or implicit commit is not allowed in stored function or
- trigger</errortext>, which makes clear the reason for the
- trigger's failure.
+ implicit <literal role="stmt">COMMIT</literal>, and so a trigger
+ cannot invoke a stored routine containing this statement. A
+ trigger which does so now fails with <errortext>ERROR 1422
+ (HY000): Explicit or implicit commit is not allowed in stored
+ function or trigger</errortext>, which makes clear the reason
+ for the trigger's failure.
</para>
</message>
@@ -19381,8 +19383,9 @@
to stop (error 1223) where a connection started a transaction,
performed updates, then issued a
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
- LOCK</literal> followed by a <literal role="stmt">COMMIT</literal>. This
- issue occurred when using the <literal>InnoDB</literal>
+ LOCK</literal> followed by a
+ <literal role="stmt">COMMIT</literal>. This issue occurred when
+ using the <literal>InnoDB</literal>
<command>innobackup</command> script.
</para>
@@ -24790,8 +24793,9 @@
<para>
If a connection was interrupted by a network error and did a
rollback, the network error code got stored into the
- <literal>BEGIN</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal> binary
- log events; that caused superfluous slave stops.
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ binary log events; that caused superfluous slave stops.
</para>
</message>
@@ -30530,13 +30534,14 @@
<para>
<command>mysqlbinlog</command> now prints a
- <literal role="stmt" condition="commit">ROLLBACK</literal> statement at the end of its output,
- in case the server crashed while it was in the process of
- writing the final entry into the last binary log named on the
- command line. This causes any half-written transaction to be
- rolled back when the output is executed. The
- <literal role="stmt" condition="commit">ROLLBACK</literal> is harmless if the binary log file
- was written and closed normally.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement at the end of its output, in case the server crashed
+ while it was in the process of writing the final entry into the
+ last binary log named on the command line. This causes any
+ half-written transaction to be rolled back when the output is
+ executed. The
+ <literal role="stmt" condition="commit">ROLLBACK</literal> is
+ harmless if the binary log file was written and closed normally.
</para>
</message>
@@ -31761,8 +31766,8 @@
TABLE</literal>, <literal role="stmt">DROP DATABASE</literal>,
and <literal role="stmt">CREATE DATABASE</literal>) were not
being written to the binary log after a
- <literal role="stmt" condition="commit">ROLLBACK</literal>. This also caused problems with
- replication.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. This
+ also caused problems with replication.
</para>
<important>
@@ -52289,10 +52294,10 @@
<para>
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
- LOCK</literal> now blocks <literal role="stmt">COMMIT</literal> statements
- if the server is running with binary logging enabled; this
- ensures that the binary log position is trustable when doing a
- full backup of tables and the binary log.
+ LOCK</literal> now blocks <literal role="stmt">COMMIT</literal>
+ statements if the server is running with binary logging enabled;
+ this ensures that the binary log position is trustable when
+ doing a full backup of tables and the binary log.
</para>
</message>
@@ -57127,8 +57132,9 @@
<para>
Added <literal>WITH CONSISTENT SNAPSHOT</literal> clause to
- <literal role="stmt" condition="commit">START TRANSACTION</literal> to begin a transaction with
- a consistent read.
+ <literal role="stmt" condition="commit">START
+ TRANSACTION</literal> to begin a transaction with a consistent
+ read.
</para>
</message>
@@ -66214,7 +66220,7 @@
<message>
<para>
- The server failed to disallow <literal>SET AUTOCOMMIT</literal>
+ The server failed to disallow <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>
in stored functions and triggers. It is allowed to change the
value of <literal>AUTOCOMMIT</literal> in stored procedures, but
a runtime error might occur if the procedure is invoked from a
@@ -76218,10 +76224,11 @@
<para>
Additional control over transaction completion was implemented.
- The <literal role="stmt">COMMIT</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ The <literal role="stmt">COMMIT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
statements support <literal>AND [NO] CHAIN</literal> and
<literal>RELEASE</literal> clauses. There is a new
- <literal>RELEASE SAVEPOINT</literal> statement. The
+ <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement. The
<literal>completion_type</literal> system variable was added for
setting the global and session default completion type.
</para>
@@ -85071,9 +85078,10 @@
<para>
<command>mysqldump --single-transaction</command> now uses
<literal>START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT
- */</literal> rather than <literal>BEGIN</literal> to start a
- transaction, so that a consistent snapshot will be used on those
- servers that support it.
+ */</literal> rather than
+ <literal role="stmt" condition="commit">BEGIN</literal> to start
+ a transaction, so that a consistent snapshot will be used on
+ those servers that support it.
</para>
</message>
@@ -87538,7 +87546,8 @@
<para>
MySQL server would crash is a fetch was performed after a
- <literal role="stmt" condition="commit">ROLLBACK</literal> when cursors were involved.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> when
+ cursors were involved.
</para>
</message>
@@ -95303,8 +95312,9 @@
<para>
<literal>InnoDB</literal>: During replication, There was a
failure to record events in the binary log that still occurred
- even in the event of a <literal role="stmt" condition="commit">ROLLBACK</literal>. For example,
- this sequence of commands:
+ even in the event of a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>. For
+ example, this sequence of commands:
</para>
<programlisting>
@@ -95317,7 +95327,8 @@
<para>
would succeed on the replication master as expected. However,
the <literal role="stmt">INSERT</literal> would fail on the
- slave because the <literal role="stmt" condition="commit">ROLLBACK</literal> would
+ slave because the
+ <literal role="stmt" condition="commit">ROLLBACK</literal> would
(erroneously) cause the <literal>CREATE TEMPORARY
TABLE</literal> statement not to be written to the binlog.
</para>
@@ -115186,8 +115197,9 @@
was stopped while executing the part of the transaction that was
in the second or later relay log, replication resumed at the
beginning of the second or later relay log, which was incorrect.
- (It should resume at <literal>BEGIN</literal>, in the first
- relay log.)
+ (It should resume at
+ <literal role="stmt" condition="commit">BEGIN</literal>, in the
+ first relay log.)
</para>
</message>
@@ -120090,8 +120102,8 @@
<para>
Concurrent <literal role="stmt">INSERT</literal> and
- <literal role="stmt" condition="commit">ROLLBACK</literal> statements from different
- connections could cause node failures.
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statements from different connections could cause node failures.
</para>
</message>
@@ -122291,7 +122303,8 @@
<literal>ALTER FUNCTION</literal>, <literal>ALTER
PROCEDURE</literal>, <literal>CREATE PROCEDURE</literal>. This
corrects a problem where these statements followed by
- <literal role="stmt" condition="commit">ROLLBACK</literal> might not be replicated properly.
+ <literal role="stmt" condition="commit">ROLLBACK</literal> might
+ not be replicated properly.
</para>
</message>
@@ -122433,10 +122446,12 @@
<message>
<para>
- A sequence of <literal>BEGIN</literal> (or <literal>SET
- AUTOCOMMIT=0</literal>),
+ A sequence of
+ <literal role="stmt" condition="commit">BEGIN</literal> (or
+ <literal>SET AUTOCOMMIT=0</literal>),
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
- LOCK</literal>, transactional update, <literal role="stmt">COMMIT</literal>,
+ LOCK</literal>, transactional update,
+ <literal role="stmt">COMMIT</literal>,
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
LOCK</literal> could hang the connection forever and possibly
the MySQL server itself. This happened for example when running
Modified: trunk/refman-4.1/dba-core.xml
===================================================================
--- trunk/refman-4.1/dba-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 727 bytes
@@ -6232,7 +6232,7 @@
to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement. See
+ <literal role="stmt" condition="commit">BEGIN</literal> statement. See
<xref linkend="commit"/>.
</para>
</listitem>
Modified: trunk/refman-4.1/news-3.23.xml
===================================================================
--- trunk/refman-4.1/news-3.23.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/news-3.23.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 3, Lines Added: 4, Lines Deleted: 4; 1281 bytes
@@ -1130,7 +1130,7 @@
<listitem>
<para>
- Wrap <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal> around
+ Wrap <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> around
transaction in the binary log. This makes replication honor
transactions.
</para>
@@ -6219,8 +6219,8 @@
<listitem>
<para>
- Added the syntax <literal>BEGIN WORK</literal> (the same as
- <literal>BEGIN</literal>).
+ Added the syntax <literal role="stmt" condition="commit">BEGIN WORK</literal> (the same as
+ <literal role="stmt" condition="commit">BEGIN</literal>).
</para>
</listitem>
@@ -6394,7 +6394,7 @@
<listitem>
<para>
- Added <literal>BEGIN</literal> statement to start a
+ Added <literal role="stmt" condition="commit">BEGIN</literal> statement to start a
transaction in <literal>AUTOCOMMIT</literal> mode.
</para>
</listitem>
Modified: trunk/refman-4.1/news-4.0.xml
===================================================================
--- trunk/refman-4.1/news-4.0.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/news-4.0.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 3, Lines Added: 4, Lines Deleted: 4; 1661 bytes
@@ -1560,7 +1560,7 @@
<para>
If a connection was interrupted by a network error and did a
rollback, the network error code got stored into the
- <literal>BEGIN</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">ROLLBACK</literal>
binary log events; that caused superfluous slave stops. (Bug
#6522)
</para>
@@ -1568,7 +1568,7 @@
<listitem>
<para>
- A sequence of <literal>BEGIN</literal> (or <literal>SET
+ A sequence of <literal role="stmt" condition="commit">BEGIN</literal> (or <literal>SET
AUTOCOMMIT=0</literal>),
<literal role="stmt" condition="flush">FLUSH TABLES WITH READ
LOCK</literal>, transactional update,
@@ -6415,8 +6415,8 @@
<listitem>
<para>
Added <literal role="stmt" condition="commit">START TRANSACTION</literal> (standard SQL
- syntax) as alias for <literal>BEGIN</literal>. This is
- recommended to use instead of <literal>BEGIN</literal> to
+ syntax) as alias for <literal role="stmt" condition="commit">BEGIN</literal>. This is
+ recommended to use instead of <literal role="stmt" condition="commit">BEGIN</literal> to
start a transaction.
</para>
</listitem>
Modified: trunk/refman-4.1/programs-client.xml
===================================================================
--- trunk/refman-4.1/programs-client.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/programs-client.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 980 bytes
@@ -6533,12 +6533,12 @@
</para>
<para>
- This option issues a <literal>BEGIN</literal> SQL statement
+ This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
before dumping data from the server. It is useful only with
transactional tables such as <literal>InnoDB</literal> and
<literal>BDB</literal>, because then it dumps the consistent
state of the database at the time when
- <literal>BEGIN</literal> was issued without blocking any
+ <literal role="stmt" condition="commit">BEGIN</literal> was issued without blocking any
applications.
</para>
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/replication.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1355 bytes
@@ -1747,9 +1747,9 @@
<listitem>
<para>
There are problems if the slave is stopped in the middle
- of a <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ of a <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
block because the slave restarts at the beginning of the
- <literal>BEGIN</literal> block.
+ <literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
</listitem>
@@ -2137,7 +2137,7 @@
<para>
If you update transactional tables from non-transactional
tables inside a
- <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal> sequence,
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> sequence,
updates to the binary log may be out of synchrony with table
states if the non-transactional table is updated before the
transaction commits. This occurs because the transaction is
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 5, Lines Added: 6, Lines Deleted: 5; 3021 bytes
@@ -2107,7 +2107,7 @@
TRANSACTION</literal> and end them with
<literal role="stmt">COMMIT</literal> or <literal role="stmt" condition="commit">ROLLBACK</literal>. Before
MySQL 4.0.11, you have to use the keyword
- <literal>BEGIN</literal> instead of <literal role="stmt" condition="commit">START
+ <literal role="stmt" condition="commit">BEGIN</literal> instead of <literal role="stmt" condition="commit">START
TRANSACTION</literal>. The following example shows two
transactions. The first is committed and the second is rolled
back.
@@ -4165,7 +4165,8 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or <literal>BEGIN</literal>
+ <literal role="stmt" condition="commit">START TRANSACTION</literal> or
+<literal role="stmt" condition="commit">BEGIN</literal>
statement and ending it with <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5210,7 +5211,7 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal>SET AUTOCOMMIT</literal> and
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements:
</para>
@@ -5224,7 +5225,7 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal>SET AUTOCOMMIT</literal> and
+ wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -6350,7 +6351,7 @@
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
<literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement, rollback does not cancel
+ <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
that statement. Further SQL statements become part of the
transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
<literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
Modified: trunk/refman-4.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 8, Lines Added: 12, Lines Deleted: 12; 4643 bytes
@@ -11,7 +11,7 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal>SET AUTOCOMMIT</literal>,
+ through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
<literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>.
</para>
@@ -57,10 +57,10 @@
<para>
The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement begins a new transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
<literal role="stmt">COMMIT</literal> commits the current transaction, making
its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal>SET
+ current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
AUTOCOMMIT</literal> statement disables or enables the default
autocommit mode for the current session.
</para>
@@ -117,12 +117,12 @@
</para>
<para>
- <literal>BEGIN</literal> and <literal>BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> was
added in MySQL 4.0.11. This is standard SQL syntax and is the
recommended way to start an ad-hoc transaction.
- <literal>BEGIN</literal> and <literal>BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
available from MySQL 3.23.17 and 3.23.19, respectively.
</para>
@@ -340,7 +340,7 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal>BEGIN</literal>,
+ statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
<literal role="stmt" condition="commit">START TRANSACTION</literal>,
@@ -381,7 +381,7 @@
<section id="savepoints">
- <title><literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -411,14 +411,14 @@
<para>
Starting from MySQL 4.0.14 and 4.1.1, <literal>InnoDB</literal>
- supports the SQL statements <literal>SAVEPOINT</literal> and
- <literal>ROLLBACK TO SAVEPOINT</literal>.
+ supports the SQL statements <literal role="stmt">SAVEPOINT</literal> and
+ <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal>.
</para>
<remark role="help-description-end"/>
<para>
- The <literal>SAVEPOINT</literal> statement sets a named
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a named
transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
@@ -426,7 +426,7 @@
</para>
<para>
- The <literal>ROLLBACK TO SAVEPOINT</literal> statement rolls back
+ The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
a transaction to the named savepoint without terminating the
transaction. Modifications that the current transaction made to
rows after the savepoint was set are undone in the rollback, but
@@ -440,7 +440,7 @@
</para>
<para>
- If the <literal>ROLLBACK TO SAVEPOINT</literal> statement returns
+ If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
the following error, it means that no savepoint with the specified
name exists:
</para>
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-4.1/storage-engines.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 717 bytes
@@ -3378,7 +3378,7 @@
<para>
You can start a transaction with the <literal role="stmt" condition="commit">START
- TRANSACTION</literal> or <literal>BEGIN</literal> statement
+ TRANSACTION</literal> or <literal role="stmt" condition="commit">BEGIN</literal> statement
to suspend autocommit, or with <literal>SET
AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 727 bytes
@@ -7193,7 +7193,7 @@
to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement. See
+ <literal role="stmt" condition="commit">BEGIN</literal> statement. See
<xref linkend="commit"/>.
</para>
</listitem>
Modified: trunk/refman-5.0/programs-client-core.xml
===================================================================
--- trunk/refman-5.0/programs-client-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 995 bytes
@@ -6918,12 +6918,12 @@
</para>
<para>
- This option issues a <literal>BEGIN</literal> SQL statement
+ This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
before dumping data from the server. It is useful only with
transactional tables such as <literal>InnoDB</literal> and
<literal>BDB</literal>, because then it dumps the consistent
state of the database at the time when
- <literal>BEGIN</literal> was issued without blocking any
+ <literal role="stmt" condition="commit">BEGIN</literal> was issued without blocking any
applications.
</para>
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1408 bytes
@@ -1038,9 +1038,9 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
the slave restarts at the beginning of the
- <literal>BEGIN</literal> block.
+ <literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
<para>
@@ -1073,7 +1073,7 @@
<para>
If you update transactional tables from non-transactional tables
- inside a <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal>
+ inside a <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal>
sequence, updates to the binary log may be out of synchrony with
table states if the non-transactional table is updated before
the transaction commits. This occurs because the transaction is
Modified: trunk/refman-5.0/se-bdb-core.xml
===================================================================
--- trunk/refman-5.0/se-bdb-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/se-bdb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 692 bytes
@@ -528,7 +528,7 @@
<para>
You can start a transaction with the <literal role="stmt" condition="commit">START
- TRANSACTION</literal> or <literal>BEGIN</literal> statement to
+ TRANSACTION</literal> or <literal role="stmt" condition="commit">BEGIN</literal> statement to
suspend autocommit, or with <literal>SET
AUTOCOMMIT=0</literal> to disable autocommit explicitly.
</para>
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 4, Lines Added: 5, Lines Deleted: 4; 2428 bytes
@@ -4226,7 +4226,8 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or <literal>BEGIN</literal>
+ <literal role="stmt" condition="commit">START TRANSACTION</literal> or
+<literal role="stmt" condition="commit">BEGIN</literal>
statement and ending it with <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5254,7 +5255,7 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal>SET AUTOCOMMIT</literal> and
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements:
</para>
@@ -5268,7 +5269,7 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal>SET AUTOCOMMIT</literal> and
+ wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -6499,7 +6500,7 @@
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
<literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement, rollback does not cancel
+ <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
that statement. Further SQL statements become part of the
transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
<literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
Modified: trunk/refman-5.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 12, Lines Added: 15, Lines Deleted: 15; 6038 bytes
@@ -11,7 +11,7 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal>SET AUTOCOMMIT</literal>,
+ through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
<literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. Beginning
with MySQL 5.0, XA transaction support is available, which enables
@@ -60,10 +60,10 @@
<para>
The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement begins a new transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
<literal role="stmt">COMMIT</literal> commits the current transaction, making
its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal>SET
+ current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
AUTOCOMMIT</literal> statement disables or enables the default
autocommit mode for the current session.
</para>
@@ -138,7 +138,7 @@
</para>
<para>
- <literal>BEGIN</literal> and <literal>BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
standard SQL syntax and is the recommended way to start an ad-hoc
@@ -157,7 +157,7 @@
</important>
<para>
- The <literal>BEGIN</literal> statement differs from the use of the
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
<literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
END</literal> compound statement. The latter does not begin a
transaction. See <xref linkend="begin-end"/>.
@@ -389,7 +389,7 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal>BEGIN</literal>,
+ statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
<literal role="stmt" condition="commit">START TRANSACTION</literal>,
@@ -423,7 +423,7 @@
</para>
<para>
- The <literal>BEGIN</literal> statement differs from the use of
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
the <literal>BEGIN</literal> keyword that starts a
<literal>BEGIN ... END</literal> compound statement. The
latter does not cause an implicit commit. See
@@ -451,7 +451,7 @@
<section id="savepoints">
- <title><literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -486,8 +486,8 @@
<para>
<literal>InnoDB</literal> supports the SQL statements
- <literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
- SAVEPOINT</literal>. Starting from MySQL 5.0.3, <literal>RELEASE
+ <literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>. Starting from MySQL 5.0.3, <literal role="stmt" condition="commit">RELEASE
SAVEPOINT</literal> and the optional <literal>WORK</literal>
keyword for <literal role="stmt" condition="commit">ROLLBACK</literal> are supported as well.
</para>
@@ -495,7 +495,7 @@
<remark role="help-description-end"/>
<para>
- The <literal>SAVEPOINT</literal> statement sets a named
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a named
transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
@@ -503,9 +503,9 @@
</para>
<para>
- The <literal>ROLLBACK TO SAVEPOINT</literal> statement rolls back
+ The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
a transaction to the named savepoint without terminating the
- transaction. (The <literal>SAVEPOINT</literal> keyword is optional
+ transaction. (The <literal role="stmt">SAVEPOINT</literal> keyword is optional
as of MySQL 5.0.3.) Modifications that the current transaction
made to rows after the savepoint was set are undone in the
rollback, but <literal>InnoDB</literal> does
@@ -518,7 +518,7 @@
</para>
<para>
- If the <literal>ROLLBACK TO SAVEPOINT</literal> statement returns
+ If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
the following error, it means that no savepoint with the specified
name exists:
</para>
@@ -528,7 +528,7 @@
</programlisting>
<para>
- The <literal>RELEASE SAVEPOINT</literal> statement removes the
+ The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
named savepoint from the set of savepoints of the current
transaction. No commit or rollback occurs. It is an error if the
savepoint does not exist.
Modified: trunk/refman-5.0/stored-programs-views.xml
===================================================================
--- trunk/refman-5.0/stored-programs-views.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.0/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1917 bytes
@@ -1115,13 +1115,13 @@
that the transactional aspects of procedure execution are
replicated correctly. That is, the server logs those
statements within the procedure that actually execute and
- modify data, and also logs <literal>BEGIN</literal>,
+ modify data, and also logs <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">COMMIT</literal>, and <literal role="stmt" condition="commit">ROLLBACK</literal>
statements as necessary. For example, if a procedure
updates only transactional tables and is executed within a
transaction that is rolled back, those updates are not
logged. If the procedure occurs within a committed
- transaction, <literal>BEGIN</literal> and
+ transaction, <literal role="stmt" condition="commit">BEGIN</literal> and
<literal role="stmt">COMMIT</literal> statements are logged with the
updates. For a procedure that executes within a
rolled-back transaction, its statements are logged using
@@ -1148,7 +1148,7 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal>BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN</literal> and
<literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
the same changes and rollbacks as on the master.
</para>
Modified: trunk/refman-5.1/dba-core.xml
===================================================================
--- trunk/refman-5.1/dba-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 727 bytes
@@ -8497,7 +8497,7 @@
to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement. See
+ <literal role="stmt" condition="commit">BEGIN</literal> statement. See
<xref linkend="commit"/>.
</para>
</listitem>
Modified: trunk/refman-5.1/programs-client-core.xml
===================================================================
--- trunk/refman-5.1/programs-client-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 960 bytes
@@ -7185,11 +7185,11 @@
</para>
<para>
- This option issues a <literal>BEGIN</literal> SQL statement
+ This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
before dumping data from the server. It is useful only with
transactional tables such as <literal>InnoDB</literal>,
because then it dumps the consistent state of the database
- at the time when <literal>BEGIN</literal> was issued without
+ at the time when <literal role="stmt" condition="commit">BEGIN</literal> was issued without
blocking any applications.
</para>
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 894 bytes
@@ -1844,9 +1844,9 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
the slave restarts at the beginning of the
- <literal>BEGIN</literal> block.
+ <literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
<para>
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 4, Lines Added: 5, Lines Deleted: 4; 2428 bytes
@@ -4925,7 +4925,8 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or <literal>BEGIN</literal>
+ <literal role="stmt" condition="commit">START TRANSACTION</literal> or
+<literal role="stmt" condition="commit">BEGIN</literal>
statement and ending it with <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5997,7 +5998,7 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal>SET AUTOCOMMIT</literal> and
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements:
</para>
@@ -6011,7 +6012,7 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal>SET AUTOCOMMIT</literal> and
+ wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -7244,7 +7245,7 @@
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
<literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement, rollback does not cancel
+ <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
that statement. Further SQL statements become part of the
transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
<literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
Modified: trunk/refman-5.1/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 12, Lines Added: 14, Lines Deleted: 14; 5772 bytes
@@ -11,7 +11,7 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal>SET AUTOCOMMIT</literal>,
+ through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
<literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. XA
transaction support enables MySQL to participate in distributed
@@ -59,10 +59,10 @@
<para>
The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement begins a new transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
<literal role="stmt">COMMIT</literal> commits the current transaction, making
its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal>SET
+ current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
AUTOCOMMIT</literal> statement disables or enables the default
autocommit mode for the current session.
</para>
@@ -136,7 +136,7 @@
</para>
<para>
- <literal>BEGIN</literal> and <literal>BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
standard SQL syntax and is the recommended way to start an ad-hoc
@@ -155,7 +155,7 @@
</important>
<para>
- The <literal>BEGIN</literal> statement differs from the use of the
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
<literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
END</literal> compound statement. The latter does not begin a
transaction. See <xref linkend="begin-end"/>.
@@ -398,7 +398,7 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal>BEGIN</literal>,
+ statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
<literal role="stmt" condition="commit">START TRANSACTION</literal>,
@@ -432,7 +432,7 @@
</para>
<para>
- The <literal>BEGIN</literal> statement differs from the use of
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
the <literal>BEGIN</literal> keyword that starts a
<literal>BEGIN ... END</literal> compound statement. The
latter does not cause an implicit commit. See
@@ -473,7 +473,7 @@
<section id="savepoints">
- <title><literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -508,8 +508,8 @@
<para>
<literal>InnoDB</literal> supports the SQL statements
- <literal>SAVEPOINT</literal>, <literal>ROLLBACK TO
- SAVEPOINT</literal>, <literal>RELEASE SAVEPOINT</literal> and the
+ <literal role="stmt">SAVEPOINT</literal>, <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>, <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> and the
optional <literal>WORK</literal> keyword for
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -517,7 +517,7 @@
<remark role="help-description-end"/>
<para>
- The <literal>SAVEPOINT</literal> statement sets a named
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a named
transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
@@ -525,7 +525,7 @@
</para>
<para>
- The <literal>ROLLBACK TO SAVEPOINT</literal> statement rolls back
+ The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
a transaction to the named savepoint without terminating the
transaction. Modifications that the current transaction made to
rows after the savepoint was set are undone in the rollback, but
@@ -539,7 +539,7 @@
</para>
<para>
- If the <literal>ROLLBACK TO SAVEPOINT</literal> statement returns
+ If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
the following error, it means that no savepoint with the specified
name exists:
</para>
@@ -549,7 +549,7 @@
</programlisting>
<para>
- The <literal>RELEASE SAVEPOINT</literal> statement removes the
+ The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
named savepoint from the set of savepoints of the current
transaction. No commit or rollback occurs. It is an error if the
savepoint does not exist.
Modified: trunk/refman-5.1/stored-programs-views.xml
===================================================================
--- trunk/refman-5.1/stored-programs-views.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-5.1/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1896 bytes
@@ -854,12 +854,12 @@
procedure execution are replicated correctly. That is, the
server logs those statements within the procedure that
actually execute and modify data, and also logs
- <literal>BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> statements as necessary. For
example, if a procedure updates only transactional tables
and is executed within a transaction that is rolled back,
those updates are not logged. If the procedure occurs
- within a committed transaction, <literal>BEGIN</literal>
+ within a committed transaction, <literal role="stmt" condition="commit">BEGIN</literal>
and <literal role="stmt">COMMIT</literal> statements are logged with
the updates. For a procedure that executes within a
rolled-back transaction, its statements are logged using
@@ -886,7 +886,7 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal>BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN</literal> and
<literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
the same changes and rollbacks as on the master.
</para>
Modified: trunk/refman-6.0/dba-core.xml
===================================================================
--- trunk/refman-6.0/dba-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/dba-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 727 bytes
@@ -8544,7 +8544,7 @@
to 1, MySQL performs an automatic <literal role="stmt">COMMIT</literal>
of any open transaction. Another way to begin a transaction
is to use a <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement. See
+ <literal role="stmt" condition="commit">BEGIN</literal> statement. See
<xref linkend="commit"/>.
</para>
</listitem>
Modified: trunk/refman-6.0/programs-client-core.xml
===================================================================
--- trunk/refman-6.0/programs-client-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/programs-client-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 960 bytes
@@ -7155,11 +7155,11 @@
</para>
<para>
- This option issues a <literal>BEGIN</literal> SQL statement
+ This option issues a <literal role="stmt" condition="commit">BEGIN</literal> SQL statement
before dumping data from the server. It is useful only with
transactional tables such as <literal>InnoDB</literal>,
because then it dumps the consistent state of the database
- at the time when <literal>BEGIN</literal> was issued without
+ at the time when <literal role="stmt" condition="commit">BEGIN</literal> was issued without
blocking any applications.
</para>
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/replication-notes.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 894 bytes
@@ -1815,9 +1815,9 @@
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do this,
there are problems if the slave is stopped in the middle of a
- <literal>BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
+ <literal role="stmt" condition="commit">BEGIN</literal>/<literal role="stmt">COMMIT</literal> block because
the slave restarts at the beginning of the
- <literal>BEGIN</literal> block.
+ <literal role="stmt" condition="commit">BEGIN</literal> block.
</para>
<para>
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 4, Lines Added: 5, Lines Deleted: 4; 2428 bytes
@@ -4792,7 +4792,8 @@
<para>
If the session has autocommit enabled, a multiple-statement
transaction can be performed by starting it with an explicit
- <literal role="stmt" condition="commit">START TRANSACTION</literal> or <literal>BEGIN</literal>
+ <literal role="stmt" condition="commit">START TRANSACTION</literal> or
+<literal role="stmt" condition="commit">BEGIN</literal>
statement and ending it with <literal role="stmt">COMMIT</literal> or
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -5864,7 +5865,7 @@
that MySQL does not have autocommit mode enabled because that
requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
- <literal>SET AUTOCOMMIT</literal> and
+ <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements:
</para>
@@ -5878,7 +5879,7 @@
If you use the <command>mysqldump</command> option
<option>--opt</option>, you get dump files that are fast to
import into an <literal>InnoDB</literal> table, even without
- wrapping them with the <literal>SET AUTOCOMMIT</literal> and
+ wrapping them with the <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal> and
<literal role="stmt">COMMIT</literal> statements.
</para>
</listitem>
@@ -7110,7 +7111,7 @@
wait timeout, it cancels the effect of the statements within
the transaction. But if the start-transaction statement was
<literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement, rollback does not cancel
+ <literal role="stmt" condition="commit">BEGIN</literal> statement, rollback does not cancel
that statement. Further SQL statements become part of the
transaction until the occurrence of <literal role="stmt">COMMIT</literal>,
<literal role="stmt" condition="commit">ROLLBACK</literal>, or some SQL statement that causes
Modified: trunk/refman-6.0/sql-syntax-transactions.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/sql-syntax-transactions.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 12, Lines Added: 14, Lines Deleted: 14; 5782 bytes
@@ -11,7 +11,7 @@
<para>
MySQL supports local transactions (within a given client session)
- through statements such as <literal>SET AUTOCOMMIT</literal>,
+ through statements such as <literal role="stmt" condition="commit">SET AUTOCOMMIT</literal>,
<literal role="stmt" condition="commit">START TRANSACTION</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal>. See <xref linkend="commit"/>. XA
transaction support enables MySQL to participate in distributed
@@ -59,10 +59,10 @@
<para>
The <literal role="stmt" condition="commit">START TRANSACTION</literal> or
- <literal>BEGIN</literal> statement begins a new transaction.
+ <literal role="stmt" condition="commit">BEGIN</literal> statement begins a new transaction.
<literal role="stmt">COMMIT</literal> commits the current transaction, making
its changes permanent. <literal role="stmt" condition="commit">ROLLBACK</literal> rolls back the
- current transaction, canceling its changes. The <literal>SET
+ current transaction, canceling its changes. The <literal role="stmt" condition="commit">SET
AUTOCOMMIT</literal> statement disables or enables the default
autocommit mode for the current session.
</para>
@@ -147,7 +147,7 @@
</para>
<para>
- <literal>BEGIN</literal> and <literal>BEGIN WORK</literal> are
+ <literal role="stmt" condition="commit">BEGIN</literal> and <literal role="stmt" condition="commit">BEGIN WORK</literal> are
supported as aliases of <literal role="stmt" condition="commit">START TRANSACTION</literal> for
initiating a transaction. <literal role="stmt" condition="commit">START TRANSACTION</literal> is
standard SQL syntax and is the recommended way to start an ad-hoc
@@ -166,7 +166,7 @@
</important>
<para>
- The <literal>BEGIN</literal> statement differs from the use of the
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of the
<literal>BEGIN</literal> keyword that starts a <literal>BEGIN ...
END</literal> compound statement. The latter does not begin a
transaction. See <xref linkend="begin-end"/>.
@@ -430,7 +430,7 @@
<listitem>
<para>
<emphasis role="bold">Transaction-control and locking
- statements.</emphasis> <literal>BEGIN</literal>,
+ statements.</emphasis> <literal role="stmt" condition="commit">BEGIN</literal>,
<literal role="stmt">LOCK TABLES</literal>, <literal>SET
AUTOCOMMIT=1</literal> (if the value is not already 1),
<literal role="stmt" condition="commit">START TRANSACTION</literal>,
@@ -465,7 +465,7 @@
</para>
<para>
- The <literal>BEGIN</literal> statement differs from the use of
+ The <literal role="stmt" condition="commit">BEGIN</literal> statement differs from the use of
the <literal>BEGIN</literal> keyword that starts a
<literal>BEGIN ... END</literal> compound statement. The
latter does not cause an implicit commit. See
@@ -539,7 +539,7 @@
<section id="savepoints">
- <title><literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
+ <title><literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> Syntax</title>
<indexterm>
@@ -574,8 +574,8 @@
<para>
<literal>InnoDB</literal> and Falcon support the SQL statements
- <literal>SAVEPOINT</literal>, <literal>ROLLBACK TO
- SAVEPOINT</literal>, <literal>RELEASE SAVEPOINT</literal> and the
+ <literal role="stmt">SAVEPOINT</literal>, <literal role="stmt" condition="commit">ROLLBACK TO
+ SAVEPOINT</literal>, <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> and the
optional <literal>WORK</literal> keyword for
<literal role="stmt" condition="commit">ROLLBACK</literal>.
</para>
@@ -583,7 +583,7 @@
<remark role="help-description-end"/>
<para>
- The <literal>SAVEPOINT</literal> statement sets a named
+ The <literal role="stmt">SAVEPOINT</literal> statement sets a named
transaction savepoint with a name of
<replaceable>identifier</replaceable>. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
@@ -591,7 +591,7 @@
</para>
<para>
- The <literal>ROLLBACK TO SAVEPOINT</literal> statement rolls back
+ The <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement rolls back
a transaction to the named savepoint without terminating the
transaction. Modifications that the current transaction made to
rows after the savepoint was set are undone in the rollback, but
@@ -605,7 +605,7 @@
</para>
<para>
- If the <literal>ROLLBACK TO SAVEPOINT</literal> statement returns
+ If the <literal role="stmt" condition="commit">ROLLBACK TO SAVEPOINT</literal> statement returns
the following error, it means that no savepoint with the specified
name exists:
</para>
@@ -615,7 +615,7 @@
</programlisting>
<para>
- The <literal>RELEASE SAVEPOINT</literal> statement removes the
+ The <literal role="stmt" condition="commit">RELEASE SAVEPOINT</literal> statement removes the
named savepoint from the set of savepoints of the current
transaction. No commit or rollback occurs. It is an error if the
savepoint does not exist.
Modified: trunk/refman-6.0/stored-programs-views.xml
===================================================================
--- trunk/refman-6.0/stored-programs-views.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-6.0/stored-programs-views.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 3; 1896 bytes
@@ -844,12 +844,12 @@
procedure execution are replicated correctly. That is, the
server logs those statements within the procedure that
actually execute and modify data, and also logs
- <literal>BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
+ <literal role="stmt" condition="commit">BEGIN</literal>, <literal role="stmt">COMMIT</literal>, and
<literal role="stmt" condition="commit">ROLLBACK</literal> statements as necessary. For
example, if a procedure updates only transactional tables
and is executed within a transaction that is rolled back,
those updates are not logged. If the procedure occurs
- within a committed transaction, <literal>BEGIN</literal>
+ within a committed transaction, <literal role="stmt" condition="commit">BEGIN</literal>
and <literal role="stmt">COMMIT</literal> statements are logged with
the updates. For a procedure that executes within a
rolled-back transaction, its statements are logged using
@@ -876,7 +876,7 @@
<para>
Updates to a mix of transactional and
non-transactional tables are logged surrounded by
- <literal>BEGIN</literal> and
+ <literal role="stmt" condition="commit">BEGIN</literal> and
<literal role="stmt" condition="commit">ROLLBACK</literal> so that slaves will make
the same changes and rollbacks as on the master.
</para>
Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml 2008-11-07 19:14:29 UTC (rev 12336)
+++ trunk/refman-common/news-innodb.xml 2008-11-07 19:14:46 UTC (rev 12337)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 674 bytes
@@ -1321,7 +1321,7 @@
<listitem>
<para>
<literal>InnoDB</literal> now supports the
- <literal>SAVEPOINT</literal> and <literal>ROLLBACK TO
+ <literal role="stmt">SAVEPOINT</literal> and <literal role="stmt" condition="commit">ROLLBACK TO
SAVEPOINT</literal> SQL statements. See
http://www.innodb.com/ibman.php#Savepoints for the syntax.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12337 - in trunk: . dynamic-docs/changelog refman-4.1 refman-5.0 refman-5.1 refman-6.0 refman-common | paul.dubois | 7 Nov |
