Sophie: postgresql8.4-docs-8.4.12-0.1mdv2010.2 i586

postgresql8.4-docs-8.4.12-0.1mdv2010.2.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Asynchronous Commit</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.4.12 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Reliability and the Write-Ahead Log"
HREF="wal.html"><LINK
REL="PREVIOUS"
TITLE="Write-Ahead Logging (WAL)"
HREF="wal-intro.html"><LINK
REL="NEXT"
TITLE="WAL Configuration"
HREF="wal-configuration.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2012-05-31T23:30:11"></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 8.4.12 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="wal-intro.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="wal.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 28. Reliability and the Write-Ahead Log</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="wal.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="wal-configuration.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="WAL-ASYNC-COMMIT"
>28.3. Asynchronous Commit</A
></H1
><A
NAME="AEN32600"
></A
><A
NAME="AEN32602"
></A
><P
>   <I
CLASS="FIRSTTERM"
>Asynchronous commit</I
> is an option that allows transactions
   to complete more quickly, at the cost that the most recent transactions may
   be lost if the database should crash.  In many applications this is an
   acceptable trade-off.
  </P
><P
>   As described in the previous section, transaction commit is normally
   <I
CLASS="FIRSTTERM"
>synchronous</I
>: the server waits for the transaction's
   <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> records to be flushed to permanent storage
   before returning a success indication to the client.  The client is
   therefore guaranteed that a transaction reported to be committed will
   be preserved, even in the event of a server crash immediately after.
   However, for short transactions this delay is a major component of the
   total transaction time.  Selecting asynchronous commit mode means that
   the server returns success as soon as the transaction is logically
   completed, before the <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> records it generated have
   actually made their way to disk.  This can provide a significant boost
   in throughput for small transactions.
  </P
><P
>   Asynchronous commit introduces the risk of data loss. There is a short
   time window between the report of transaction completion to the client
   and the time that the transaction is truly committed (that is, it is
   guaranteed not to be lost if the server crashes).  Thus asynchronous
   commit should not be used if the client will take external actions
   relying on the assumption that the transaction will be remembered.
   As an example, a bank would certainly not use asynchronous commit for
   a transaction recording an ATM's dispensing of cash.  But in many
   scenarios, such as event logging, there is no need for a strong
   guarantee of this kind.
  </P
><P
>   The risk that is taken by using asynchronous commit is of data loss,
   not data corruption.  If the database should crash, it will recover
   by replaying <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> up to the last record that was
   flushed.  The database will therefore be restored to a self-consistent
   state, but any transactions that were not yet flushed to disk will
   not be reflected in that state.  The net effect is therefore loss of
   the last few transactions.  Because the transactions are replayed in
   commit order, no inconsistency can be introduced &mdash; for example,
   if transaction B made changes relying on the effects of a previous
   transaction A, it is not possible for A's effects to be lost while B's
   effects are preserved.
  </P
><P
>   The user can select the commit mode of each transaction, so that
   it is possible to have both synchronous and asynchronous commit
   transactions running concurrently.  This allows flexible trade-offs
   between performance and certainty of transaction durability.
   The commit mode is controlled by the user-settable parameter
   <A
HREF="runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT"
>synchronous_commit</A
>, which can be changed in any of
   the ways that a configuration parameter can be set.  The mode used for
   any one transaction depends on the value of
   <TT
CLASS="VARNAME"
>synchronous_commit</TT
> when transaction commit begins.
  </P
><P
>   Certain utility commands, for instance <TT
CLASS="COMMAND"
>DROP TABLE</TT
>, are
   forced to commit synchronously regardless of the setting of
   <TT
CLASS="VARNAME"
>synchronous_commit</TT
>.  This is to ensure consistency
   between the server's file system and the logical state of the database.
   The commands supporting two-phase commit, such as <TT
CLASS="COMMAND"
>PREPARE
   TRANSACTION</TT
>, are also always synchronous.
  </P
><P
>   If the database crashes during the risk window between an
   asynchronous commit and the writing of the transaction's
   <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> records,
   then changes made during that transaction <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>will</I
></SPAN
> be lost.
   The duration of the
   risk window is limited because a background process (the <SPAN
CLASS="QUOTE"
>"WAL
   writer"</SPAN
>) flushes unwritten <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> records to disk
   every <A
HREF="runtime-config-wal.html#GUC-WAL-WRITER-DELAY"
>wal_writer_delay</A
> milliseconds.
   The actual maximum duration of the risk window is three times
   <TT
CLASS="VARNAME"
>wal_writer_delay</TT
> because the WAL writer is
   designed to favor writing whole pages at a time during busy periods.
  </P
><DIV
CLASS="CAUTION"
><P
></P
><TABLE
CLASS="CAUTION"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Caution</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>    An immediate-mode shutdown is equivalent to a server crash, and will
    therefore cause loss of any unflushed asynchronous commits.
   </P
></TD
></TR
></TABLE
></DIV
><P
>   Asynchronous commit provides behavior different from setting
   <A
HREF="runtime-config-wal.html#GUC-FSYNC"
>fsync</A
> = off.
   <TT
CLASS="VARNAME"
>fsync</TT
> is a server-wide
   setting that will alter the behavior of all transactions.  It disables
   all logic within <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> that attempts to synchronize
   writes to different portions of the database, and therefore a system
   crash (that is, a hardware or operating system crash, not a failure of
   <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> itself) could result in arbitrarily bad
   corruption of the database state.  In many scenarios, asynchronous
   commit provides most of the performance improvement that could be
   obtained by turning off <TT
CLASS="VARNAME"
>fsync</TT
>, but without the risk
   of data corruption.
  </P
><P
>   <A
HREF="runtime-config-wal.html#GUC-COMMIT-DELAY"
>commit_delay</A
> also sounds very similar to
   asynchronous commit, but it is actually a synchronous commit method
   (in fact, <TT
CLASS="VARNAME"
>commit_delay</TT
> is ignored during an
   asynchronous commit).  <TT
CLASS="VARNAME"
>commit_delay</TT
> causes a delay
   just before a synchronous commit attempts to flush
   <ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> to disk, in the hope that a single flush
   executed by one such transaction can also serve other transactions
   committing at about the same time.  Setting <TT
CLASS="VARNAME"
>commit_delay</TT
>
   can only help when there are many concurrently committing transactions,
   and it is difficult to tune it to a value that actually helps rather
   than hurting throughput.
  </P
></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="wal-intro.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="wal-configuration.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Write-Ahead Logging (<ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
>)</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="wal.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><ACRONYM
CLASS="ACRONYM"
>WAL</ACRONYM
> Configuration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>