begriffs open source - ai-pg/blob - full-docs/html/wal-async-commit.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>28.4. Asynchronous Commit</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="wal-intro.html" title="28.3. Write-Ahead Logging (WAL)" /><link rel="next" href="wal-configuration.html" title="28.5. WAL Configuration" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">28.4. Asynchronous Commit</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="wal-intro.html" title="28.3. Write-Ahead Logging (WAL)">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><th width="60%" align="center">Chapter 28. Reliability and the Write-Ahead Log</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="wal-configuration.html" title="28.5. WAL Configuration">Next</a></td></tr></table><hr /></div><div class="sect1" id="WAL-ASYNC-COMMIT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">28.4. Asynchronous Commit <a href="#WAL-ASYNC-COMMIT" class="id_link">#</a></h2></div></div></div><a id="id-1.6.15.6.2" class="indexterm"></a><a id="id-1.6.15.6.3" class="indexterm"></a><p>
   3    <em class="firstterm">Asynchronous commit</em> is an option that allows transactions
   4    to complete more quickly, at the cost that the most recent transactions may
   5    be lost if the database should crash.  In many applications this is an
   6    acceptable trade-off.
   7   </p><p>
   8    As described in the previous section, transaction commit is normally
   9    <em class="firstterm">synchronous</em>: the server waits for the transaction's
  10    <acronym class="acronym">WAL</acronym> records to be flushed to permanent storage
  11    before returning a success indication to the client.  The client is
  12    therefore guaranteed that a transaction reported to be committed will
  13    be preserved, even in the event of a server crash immediately after.
  14    However, for short transactions this delay is a major component of the
  15    total transaction time.  Selecting asynchronous commit mode means that
  16    the server returns success as soon as the transaction is logically
  17    completed, before the <acronym class="acronym">WAL</acronym> records it generated have
  18    actually made their way to disk.  This can provide a significant boost
  19    in throughput for small transactions.
  20   </p><p>
  21    Asynchronous commit introduces the risk of data loss. There is a short
  22    time window between the report of transaction completion to the client
  23    and the time that the transaction is truly committed (that is, it is
  24    guaranteed not to be lost if the server crashes).  Thus asynchronous
  25    commit should not be used if the client will take external actions
  26    relying on the assumption that the transaction will be remembered.
  27    As an example, a bank would certainly not use asynchronous commit for
  28    a transaction recording an ATM's dispensing of cash.  But in many
  29    scenarios, such as event logging, there is no need for a strong
  30    guarantee of this kind.
  31   </p><p>
  32    The risk that is taken by using asynchronous commit is of data loss,
  33    not data corruption.  If the database should crash, it will recover
  34    by replaying <acronym class="acronym">WAL</acronym> up to the last record that was
  35    flushed.  The database will therefore be restored to a self-consistent
  36    state, but any transactions that were not yet flushed to disk will
  37    not be reflected in that state.  The net effect is therefore loss of
  38    the last few transactions.  Because the transactions are replayed in
  39    commit order, no inconsistency can be introduced — for example,
  40    if transaction B made changes relying on the effects of a previous
  41    transaction A, it is not possible for A's effects to be lost while B's
  42    effects are preserved.
  43   </p><p>
  44    The user can select the commit mode of each transaction, so that
  45    it is possible to have both synchronous and asynchronous commit
  46    transactions running concurrently.  This allows flexible trade-offs
  47    between performance and certainty of transaction durability.
  48    The commit mode is controlled by the user-settable parameter
  49    <a class="xref" href="runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT">synchronous_commit</a>, which can be changed in any of
  50    the ways that a configuration parameter can be set.  The mode used for
  51    any one transaction depends on the value of
  52    <code class="varname">synchronous_commit</code> when transaction commit begins.
  53   </p><p>
  54    Certain utility commands, for instance <code class="command">DROP TABLE</code>, are
  55    forced to commit synchronously regardless of the setting of
  56    <code class="varname">synchronous_commit</code>.  This is to ensure consistency
  57    between the server's file system and the logical state of the database.
  58    The commands supporting two-phase commit, such as <code class="command">PREPARE
  59    TRANSACTION</code>, are also always synchronous.
  60   </p><p>
  61    If the database crashes during the risk window between an
  62    asynchronous commit and the writing of the transaction's
  63    <acronym class="acronym">WAL</acronym> records,
  64    then changes made during that transaction <span class="emphasis"><em>will</em></span> be lost.
  65    The duration of the
  66    risk window is limited because a background process (the <span class="quote">“<span class="quote">WAL
  67    writer</span>”</span>) flushes unwritten <acronym class="acronym">WAL</acronym> records to disk
  68    every <a class="xref" href="runtime-config-wal.html#GUC-WAL-WRITER-DELAY">wal_writer_delay</a> milliseconds.
  69    The actual maximum duration of the risk window is three times
  70    <code class="varname">wal_writer_delay</code> because the WAL writer is
  71    designed to favor writing whole pages at a time during busy periods.
  72   </p><div class="caution"><h3 class="title">Caution</h3><p>
  73     An immediate-mode shutdown is equivalent to a server crash, and will
  74     therefore cause loss of any unflushed asynchronous commits.
  75    </p></div><p>
  76    Asynchronous commit provides behavior different from setting
  77    <a class="xref" href="runtime-config-wal.html#GUC-FSYNC">fsync</a> = off.
  78    <code class="varname">fsync</code> is a server-wide
  79    setting that will alter the behavior of all transactions.  It disables
  80    all logic within <span class="productname">PostgreSQL</span> that attempts to synchronize
  81    writes to different portions of the database, and therefore a system
  82    crash (that is, a hardware or operating system crash, not a failure of
  83    <span class="productname">PostgreSQL</span> itself) could result in arbitrarily bad
  84    corruption of the database state.  In many scenarios, asynchronous
  85    commit provides most of the performance improvement that could be
  86    obtained by turning off <code class="varname">fsync</code>, but without the risk
  87    of data corruption.
  88   </p><p>
  89    <a class="xref" href="runtime-config-wal.html#GUC-COMMIT-DELAY">commit_delay</a> also sounds very similar to
  90    asynchronous commit, but it is actually a synchronous commit method
  91    (in fact, <code class="varname">commit_delay</code> is ignored during an
  92    asynchronous commit).  <code class="varname">commit_delay</code> causes a delay
  93    just before a transaction flushes <acronym class="acronym">WAL</acronym> to disk, in
  94    the hope that a single flush executed by one such transaction can also
  95    serve other transactions committing at about the same time.  The
  96    setting can be thought of as a way of increasing the time window in
  97    which transactions can join a group about to participate in a single
  98    flush, to amortize the cost of the flush among multiple transactions.
  99   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="wal-intro.html" title="28.3. Write-Ahead Logging (WAL)">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="wal-configuration.html" title="28.5. WAL Configuration">Next</a></td></tr><tr><td width="40%" align="left" valign="top">28.3. Write-Ahead Logging (<acronym class="acronym">WAL</acronym>) </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 28.5. <acronym class="acronym">WAL</acronym> Configuration</td></tr></table></div></body></html>