diff options
Diffstat (limited to 'doc/src/sgml/html/wal-async-commit.html')
| -rw-r--r-- | doc/src/sgml/html/wal-async-commit.html | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/doc/src/sgml/html/wal-async-commit.html b/doc/src/sgml/html/wal-async-commit.html new file mode 100644 index 0000000..a397fd5 --- /dev/null +++ b/doc/src/sgml/html/wal-async-commit.html @@ -0,0 +1,99 @@ +<?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>30.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="30.3. Write-Ahead Logging (WAL)" /><link rel="next" href="wal-configuration.html" title="30.5. WAL Configuration" /></head><body id="docContent" class="container-fluid col-10"><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">30.4. Asynchronous Commit</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="wal-intro.html" title="30.3. Write-Ahead Logging (WAL)">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="wal.html" title="Chapter 30. Reliability and the Write-Ahead Log">Up</a></td><th width="60%" align="center">Chapter 30. Reliability and the Write-Ahead Log</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 14.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="wal-configuration.html" title="30.5. 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">30.4. Asynchronous Commit</h2></div></div></div><a id="id-1.6.17.6.2" class="indexterm"></a><a id="id-1.6.17.6.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 xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navfooter"><hr></hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="wal-intro.html" title="30.3. Write-Ahead Logging (WAL)">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="wal.html" title="Chapter 30. Reliability and the Write-Ahead Log">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="wal-configuration.html" title="30.5. WAL Configuration">Next</a></td></tr><tr><td width="40%" align="left" valign="top">30.3. Write-Ahead Logging (<acronym xmlns="http://www.w3.org/1999/xhtml" class="acronym">WAL</acronym>) </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 14.5 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 30.5. <acronym xmlns="http://www.w3.org/1999/xhtml" class="acronym">WAL</acronym> Configuration</td></tr></table></div></body></html>
\ No newline at end of file |