Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit932a271

Browse files
committed
Fix erroneous documentation of synchronous_commit = remote_write.
The docs claimed that this mode only waits for the standby to receive WALdata, but actually it waits for the data to be written out to the standby'sOS; which is a pretty significant difference because it removes the risk ofcrash of the walreceiver process.
1 parent03af60c commit932a271

File tree

2 files changed

+38
-26
lines changed

2 files changed

+38
-26
lines changed

‎doc/src/sgml/config.sgml‎

Lines changed: 28 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1634,8 +1634,9 @@ SET ENABLE_SEQSCAN TO OFF;
16341634
<para>
16351635
Specifies whether transaction commit will wait for WAL records
16361636
to be written to disk before the command returns a <quote>success</>
1637-
indication to the client. Valid values are <literal>on</>, <literal>remote_write</>,
1638-
<literal>local</>, and <literal>off</>. The default, and safe, value
1637+
indication to the client. Valid values are <literal>on</>,
1638+
<literal>remote_write</>, <literal>local</>, and <literal>off</>.
1639+
The default, and safe, setting
16391640
is <literal>on</>. When <literal>off</>, there can be a delay between
16401641
when success is reported to the client and when the transaction is
16411642
really guaranteed to be safe against a server crash. (The maximum
@@ -1652,27 +1653,34 @@ SET ENABLE_SEQSCAN TO OFF;
16521653
</para>
16531654
<para>
16541655
If <xref linkend="guc-synchronous-standby-names"> is set, this
1655-
parameter also controls whether or not transaction commit will wait
1656-
for the transaction's WAL records to be flushed to disk and replicated
1657-
to the standby server. When <literal>remote_write</>, the commit wait will
1658-
last until a reply from the current synchronous standby indicates
1659-
it has received the commit record of the transaction to memory.
1660-
Normally this causes no data loss at the time of failover. However,
1661-
if both primary and standby crash, and the database cluster of
1662-
the primary gets corrupted, recent committed transactions might
1663-
be lost. When <literal>on</>, the commit wait will last until a reply
1664-
from the current synchronous standby indicates it has flushed
1665-
the commit record of the transaction to durable storage. This
1666-
avoids any data loss unless the database cluster of both primary and
1667-
standby gets corrupted simultaneously. If synchronous
1656+
parameter also controls whether or not transaction commits will wait
1657+
for the transaction's WAL records to be replicated to the standby
1658+
server.
1659+
When set to <literal>on</>, commits will wait until a reply
1660+
from the current synchronous standby indicates it has received
1661+
the commit record of the transaction and flushed it to disk. This
1662+
ensures the transaction will not be lost unless both primary and
1663+
standby suffer corruption of their database storage.
1664+
When set to <literal>remote_write</>, commits will wait
1665+
until a reply from the current synchronous standby indicates it has
1666+
received the commit record of the transaction and written it out to
1667+
the standby's operating system, but the data has not necessarily
1668+
reached stable storage on the standby. This setting is sufficient to
1669+
ensure data preservation even if the standby instance of
1670+
<productname>PostgreSQL</> were to crash, but not if the standby
1671+
suffers an operating-system-level crash.
1672+
</para>
1673+
<para>
1674+
When synchronous
16681675
replication is in use, it will normally be sensible either to wait
1669-
for both local flush and replication of WAL records, or
1676+
for both local flushto diskand replication of WAL records, or
16701677
to allow the transaction to commit asynchronously. However, the
1671-
special value <literal>local</> is available for transactions that
1678+
setting <literal>local</> is available for transactions that
16721679
wish to wait for local flush to disk, but not synchronous replication.
1673-
If <varname>synchronous_standby_names</> is not set, <literal>on</>,
1674-
<literal>remote_write</> and <literal>local</> provide the same
1675-
synchronization level; transaction commit only waits for local flush.
1680+
If <varname>synchronous_standby_names</> is not set, the settings
1681+
<literal>on</>, <literal>remote_write</> and <literal>local</> all
1682+
provide the same synchronization level: transaction commits only wait
1683+
for local flush to disk.
16761684
</para>
16771685
<para>
16781686
This parameter can be changed at any time; the behavior for any

‎doc/src/sgml/high-availability.sgml‎

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -989,9 +989,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
989989
<xref linkend="runtime-config-replication-master">.)
990990
This configuration will cause each commit to wait for
991991
confirmation that the standby has written the commit record to durable
992-
storage, even if that takes a very long time.
992+
storage.
993993
<varname>synchronous_commit</> can be set by individual
994-
users, so can be configured in the configuration file, for particular
994+
users, soitcan be configured in the configuration file, for particular
995995
users or databases, or dynamically by applications, in order to control
996996
the durability guarantee on a per-transaction basis.
997997
</para>
@@ -1015,10 +1015,14 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
10151015
<para>
10161016
Setting <varname>synchronous_commit</> to <literal>remote_write</> will
10171017
cause each commit to wait for confirmation that the standby has received
1018-
the commit record to memory. This provides a lower level of durability
1019-
than <literal>on</> does. However, it's a practically useful setting
1020-
because it can decrease the response time for the transaction, and causes
1021-
no data loss unless both the primary and the standby crashes and
1018+
the commit record and written it out to its own operating system, but not
1019+
for the data to be flushed to disk on the standby. This
1020+
setting provides a weaker guarantee of durability than <literal>on</>
1021+
does: the standby could lose the data in the event of an operating system
1022+
crash, though not a <productname>PostgreSQL</> crash.
1023+
However, it's a useful setting in practice
1024+
because it can decrease the response time for the transaction.
1025+
Data loss could only occur if both the primary and the standby crash and
10221026
the database of the primary gets corrupted at the same time.
10231027
</para>
10241028

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp