|
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <!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>29.3. 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 V1.79.1" /><link rel="prev" href="wal-intro.html" title="29.2. Write-Ahead Logging (WAL)" /><link rel="next" href="wal-configuration.html" title="29.4. WAL Configuration" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">29.3. Asynchronous Commit</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="wal-intro.html" title="29.2. Write-Ahead Logging (WAL)">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="wal.html" title="Chapter 29. Reliability and the Write-Ahead Log">Up</a></td><th width="60%" align="center">Chapter 29. Reliability and the Write-Ahead Log</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="wal-configuration.html" title="29.4. WAL Configuration">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="WAL-ASYNC-COMMIT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">29.3. Asynchronous Commit</h2></div></div></div><a id="id-1.6.16.5.2" class="indexterm"></a><a id="id-1.6.16.5.3" class="indexterm"></a><p>
- <em class="firstterm">Asynchronous commit</em> 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
- <em class="firstterm">synchronous</em>: 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 — 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 class="xref" 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
- <code class="varname">synchronous_commit</code> when transaction commit begins.
- </p><p>
- Certain utility commands, for instance <code class="command">DROP TABLE</code>, are
- forced to commit synchronously regardless of the setting of
- <code class="varname">synchronous_commit</code>. 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 <code class="command">PREPARE
- TRANSACTION</code>, 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"><em>will</em></span> be lost.
- The duration of the
- risk window is limited because a background process (the <span class="quote">“<span class="quote">WAL
- writer</span>”</span>) flushes unwritten <acronym class="acronym">WAL</acronym> records to disk
- every <a class="xref" 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
- <code class="varname">wal_writer_delay</code> because the WAL writer is
- designed to favor writing whole pages at a time during busy periods.
- </p><div class="caution"><h3 class="title">Caution</h3><p>
- An immediate-mode shutdown is equivalent to a server crash, and will
- therefore cause loss of any unflushed asynchronous commits.
- </p></div><p>
- Asynchronous commit provides behavior different from setting
- <a class="xref" href="runtime-config-wal.html#GUC-FSYNC">fsync</a> = off.
- <code class="varname">fsync</code> 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 <code class="varname">fsync</code>, but without the risk
- of data corruption.
- </p><p>
- <a class="xref" 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, <code class="varname">commit_delay</code> is ignored during an
- asynchronous commit). <code class="varname">commit_delay</code> causes a delay
- just before a transaction flushes <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. The
- setting can be thought of as a way of increasing the time window in
- which transactions can join a group about to participate in a single
- flush, to amortize the cost of the flush among multiple transactions.
- </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">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="wal.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="wal-configuration.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">29.2. Write-Ahead Logging (<acronym class="acronym">WAL</acronym>) </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 29.4. <acronym class="acronym">WAL</acronym> Configuration</td></tr></table></div></body></html>
|
