<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Transactions</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REV="MADE" HREF="mailto:pgsql-docs@postgresql.org"><LINK REL="HOME" TITLE="PostgreSQL 7.4.1 Documentation" HREF="index.html"><LINK REL="UP" TITLE="Advanced Features" HREF="tutorial-advanced.html"><LINK REL="PREVIOUS" TITLE="Foreign Keys" HREF="tutorial-fk.html"><LINK REL="NEXT" TITLE="Inheritance" HREF="tutorial-inheritance.html"><LINK REL="STYLESHEET" TYPE="text/css" HREF="stylesheet.css"><META NAME="creation" CONTENT="2003-12-22T03:48:47"></HEAD ><BODY CLASS="SECT1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="5" ALIGN="center" VALIGN="bottom" >PostgreSQL 7.4.1 Documentation</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="tutorial-fk.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="tutorial-advanced.html" >Fast Backward</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" >Chapter 3. Advanced Features</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="top" ><A HREF="tutorial-advanced.html" >Fast Forward</A ></TD ><TD WIDTH="10%" ALIGN="right" VALIGN="top" ><A HREF="tutorial-inheritance.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="TUTORIAL-TRANSACTIONS" >3.4. Transactions</A ></H1 ><A NAME="AEN919" ></A ><P > <I CLASS="FIRSTTERM" >Transactions</I > are a fundamental concept of all database 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, then none of the steps affect the database at all. </P ><P > For example, consider a bank database that contains balances for various customer accounts, as well as total deposit balances for branches. Suppose that we want to record a payment of $100.00 from Alice's account to Bob's account. Simplifying outrageously, the SQL commands for this might look like </P><PRE CLASS="PROGRAMLISTING" >UPDATE accounts SET balance = balance - 100.00 WHERE name = 'Alice'; UPDATE branches SET balance = balance - 100.00 WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice'); UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob'; UPDATE branches SET balance = balance + 100.00 WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');</PRE ><P> </P ><P > The details of these commands are not important here; the important point is that there are several separate updates involved to accomplish this rather simple operation. Our bank's officers will want to be assured that either all these updates happen, or none of them happen. It would certainly not do for a system failure to result in Bob receiving $100.00 that was not debited from Alice. Nor would Alice long remain a happy customer if she was debited without Bob being credited. We need a guarantee that if something goes wrong partway through the operation, none of the steps executed so far will take effect. Grouping the updates into a <I CLASS="FIRSTTERM" >transaction</I > gives us this guarantee. A transaction is said to be <I CLASS="FIRSTTERM" >atomic</I >: from the point of view of other transactions, it either happens completely or not at all. </P ><P > We also want a guarantee that once a transaction is completed and acknowledged by the database system, it has indeed been permanently recorded and won't be lost even if a crash ensues shortly thereafter. For example, if we are recording a cash withdrawal by Bob, we do not want any chance that the debit to his account will disappear in a crash just as he walks out the bank door. A transactional database guarantees that all the updates made by a transaction are logged in permanent storage (i.e., on disk) before the transaction is reported complete. </P ><P > Another important property of transactional databases is closely related to the notion of atomic updates: when multiple transactions are running concurrently, each one should not be able to see the incomplete changes made by others. For example, if one transaction is busy totalling all the branch balances, it would not do for it to include the debit from Alice's branch but not the credit to Bob's branch, nor vice versa. So transactions must be all-or-nothing not only in terms of their permanent effect on the database, but also in terms of their visibility as they happen. The updates made so far by an open transaction are invisible to other transactions until the transaction completes, whereupon all the updates become visible simultaneously. </P ><P > In <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN >, a transaction is set up by surrounding the SQL commands of the transaction with <TT CLASS="COMMAND" >BEGIN</TT > and <TT CLASS="COMMAND" >COMMIT</TT > commands. So our banking transaction would actually look like </P><PRE CLASS="PROGRAMLISTING" >BEGIN; UPDATE accounts SET balance = balance - 100.00 WHERE name = 'Alice'; -- etc etc COMMIT;</PRE ><P> </P ><P > 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 <TT CLASS="COMMAND" >ROLLBACK</TT > instead of <TT CLASS="COMMAND" >COMMIT</TT >, and all our updates so far will be canceled. </P ><P > <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > actually treats every SQL statement as being executed within a transaction. If you do not issue a <TT CLASS="COMMAND" >BEGIN</TT > command, then each individual statement has an implicit <TT CLASS="COMMAND" >BEGIN</TT > and (if successful) <TT CLASS="COMMAND" >COMMIT</TT > wrapped around it. A group of statements surrounded by <TT CLASS="COMMAND" >BEGIN</TT > and <TT CLASS="COMMAND" >COMMIT</TT > is sometimes called a <I CLASS="FIRSTTERM" >transaction block</I >. </P ><DIV CLASS="NOTE" ><BLOCKQUOTE CLASS="NOTE" ><P ><B >Note: </B > Some client libraries issue <TT CLASS="COMMAND" >BEGIN</TT > and <TT CLASS="COMMAND" >COMMIT</TT > commands automatically, so that you may get the effect of transaction blocks without asking. Check the documentation for the interface you are using. </P ></BLOCKQUOTE ></DIV ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="tutorial-fk.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="tutorial-inheritance.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Foreign Keys</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="tutorial-advanced.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Inheritance</TD ></TR ></TABLE ></DIV ></BODY ></HTML >