1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
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 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 15.4 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 /></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 class="navfooter"><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 class="acronym">WAL</acronym>) </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 15.4 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 30.5. <acronym class="acronym">WAL</acronym> Configuration</td></tr></table></div></body></html>
|
