From: Tom Lane Date: Wed, 22 Aug 2012 18:04:02 +0000 (-0400) Subject: Fix erroneous documentation of synchronous_commit = remote_write. X-Git-Tag: REL9_3_BETA1~1042 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=932a271956afac90a676b946fd3e356b45581445;p=postgresql Fix erroneous documentation of synchronous_commit = remote_write. The docs claimed that this mode only waits for the standby to receive WAL data, but actually it waits for the data to be written out to the standby's OS; which is a pretty significant difference because it removes the risk of crash of the walreceiver process. --- diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 6e6860dd5b..d5fa94e2d4 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1634,8 +1634,9 @@ SET ENABLE_SEQSCAN TO OFF; Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a success - indication to the client. Valid values are on, remote_write, - local, and off. The default, and safe, value + indication to the client. Valid values are on, + remote_write, local, and off. + The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum @@ -1652,27 +1653,34 @@ SET ENABLE_SEQSCAN TO OFF; If is set, this - parameter also controls whether or not transaction commit will wait - for the transaction's WAL records to be flushed to disk and replicated - to the standby server. When remote_write, the commit wait will - last until a reply from the current synchronous standby indicates - it has received the commit record of the transaction to memory. - Normally this causes no data loss at the time of failover. However, - if both primary and standby crash, and the database cluster of - the primary gets corrupted, recent committed transactions might - be lost. When on, the commit wait will last until a reply - from the current synchronous standby indicates it has flushed - the commit record of the transaction to durable storage. This - avoids any data loss unless the database cluster of both primary and - standby gets corrupted simultaneously. If synchronous + parameter also controls whether or not transaction commits will wait + for the transaction's WAL records to be replicated to the standby + server. + When set to on, commits will wait until a reply + from the current synchronous standby indicates it has received + the commit record of the transaction and flushed it to disk. This + ensures the transaction will not be lost unless both primary and + standby suffer corruption of their database storage. + When set to remote_write, commits will wait + until a reply from the current synchronous standby indicates it has + received the commit record of the transaction and written it out to + the standby's operating system, but the data has not necessarily + reached stable storage on the standby. This setting is sufficient to + ensure data preservation even if the standby instance of + PostgreSQL were to crash, but not if the standby + suffers an operating-system-level crash. + + + When synchronous replication is in use, it will normally be sensible either to wait - for both local flush and replication of WAL records, or + for both local flush to disk and replication of WAL records, or to allow the transaction to commit asynchronously. However, the - special value local is available for transactions that + setting local is available for transactions that wish to wait for local flush to disk, but not synchronous replication. - If synchronous_standby_names is not set, on, - remote_write and local provide the same - synchronization level; transaction commit only waits for local flush. + If synchronous_standby_names is not set, the settings + on, remote_write and local all + provide the same synchronization level: transaction commits only wait + for local flush to disk. This parameter can be changed at any time; the behavior for any diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 52e3c84a81..f3816085b6 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -989,9 +989,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' .) This configuration will cause each commit to wait for confirmation that the standby has written the commit record to durable - storage, even if that takes a very long time. + storage. synchronous_commit can be set by individual - users, so can be configured in the configuration file, for particular + users, so it can be configured in the configuration file, for particular users or databases, or dynamically by applications, in order to control the durability guarantee on a per-transaction basis. @@ -1015,10 +1015,14 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' Setting synchronous_commit to remote_write will cause each commit to wait for confirmation that the standby has received - the commit record to memory. This provides a lower level of durability - than on does. However, it's a practically useful setting - because it can decrease the response time for the transaction, and causes - no data loss unless both the primary and the standby crashes and + the commit record and written it out to its own operating system, but not + for the data to be flushed to disk on the standby. This + setting provides a weaker guarantee of durability than on + does: the standby could lose the data in the event of an operating system + crash, though not a PostgreSQL crash. + However, it's a useful setting in practice + because it can decrease the response time for the transaction. + Data loss could only occur if both the primary and the standby crash and the database of the primary gets corrupted at the same time.