systems. The essential point of a transaction is that it bundles
multiple steps into a single, all-or-nothing operation. The intermediate
states between the steps are not visible to other concurrent transactions,
- and if some failure occurs that prevents the transaction from completing,
+ and if an error occurs that prevents the transaction from completing,
then none of the steps affect the database at all.
</para>
<para>
In <productname>PostgreSQL</productname>, a transaction is set up by surrounding
the SQL commands of the transaction with
- <command>BEGIN</command> and <command>COMMIT</command> commands. So our banking
+ <xref linkend="sql-begin"/> and
+ <xref linkend="sql-commit"/> commands. So our banking
transaction would actually look like:
<programlisting>
<para>
If, partway through the transaction, we decide we do not want to
commit (perhaps we just noticed that Alice's balance went negative),
- we can issue the command <command>ROLLBACK</command> instead of
+ we can issue the command <xref linkend="sql-rollback"/> instead of
<command>COMMIT</command>, and all our updates so far will be canceled.
</para>
</para>
</note>
+ <para>
+ When an error occurs within a transaction block the transaction is not
+ ended, but instead goes into an aborted state. While in this state all
+ commands except <xref linkend="sql-commit"/> and
+ <xref linkend="sql-rollback"/> are rejected. Importantly, both those
+ commands will behave identically — they roll back and close the
+ failed transaction, returning the session to a state where new commands
+ can be issued. They will also automatically begin a new transaction if
+ executed with the <literal>AND CHAIN</literal> option.
+ </para>
+
<para>
It's possible to control the statements in a transaction in a more
granular fashion through the use of <firstterm>savepoints</firstterm>. Savepoints
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs.
</para>
+
+ <para>
+ If the transaction is in an aborted state then no changes will be made
+ and the effect of the <command>COMMIT</command> will be identical to that
+ of <command>ROLLBACK</command>, including the command tag output.
+ </para>
+
+ <para>
+ In either case, if the <literal>AND CHAIN</literal> parameter is
+ specified then a new, identically configured, transaction is started.
+ </para>
+
+ <para>
+ For more information regarding transactions see
+ <xref linkend="tutorial-transactions"/>.
+ </para>
</refsect1>
<refsect1>
</variablelist>
</refsect1>
+ <refsect1>
+ <title>Outputs</title>
+
+ <para>
+ On successful completion of a non-aborted transaction,
+ a <command>COMMIT</command> command returns a command tag of the form
+<screen>
+COMMIT
+</screen>
+ </para>
+ <para>
+ However, in an aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+ROLLBACK
+</screen>
+ </para>
+ </refsect1>
+
<refsect1>
<title>Notes</title>
<title>Compatibility</title>
<para>
- The command <command>COMMIT</command> conforms to the SQL standard. The
- form <literal>COMMIT TRANSACTION</literal> is a PostgreSQL extension.
+ The command <command>COMMIT</command> conforms to the SQL standard, except
+ that no exception condition is raised in the case where the transaction
+ was already aborted.
+ </para>
+
+ <para>
+ The form <literal>COMMIT TRANSACTION</literal> is a PostgreSQL extension.
</para>
</refsect1>
<simplelist type="inline">
<member><xref linkend="sql-begin"/></member>
<member><xref linkend="sql-rollback"/></member>
+ <member><xref linkend="tutorial-transactions"/></member>
</simplelist>
</refsect1>
</refentry>