diff options
Diffstat (limited to 'doc/src/sgml/config.sgml')
| -rw-r--r-- | doc/src/sgml/config.sgml | 48 |
1 files changed, 28 insertions, 20 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 6e6860dd5b3..d5fa94e2d49 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1634,8 +1634,9 @@ SET ENABLE_SEQSCAN TO OFF; <para> Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a <quote>success</> - indication to the client. Valid values are <literal>on</>, <literal>remote_write</>, - <literal>local</>, and <literal>off</>. The default, and safe, value + indication to the client. Valid values are <literal>on</>, + <literal>remote_write</>, <literal>local</>, and <literal>off</>. + The default, and safe, setting is <literal>on</>. When <literal>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; </para> <para> If <xref linkend="guc-synchronous-standby-names"> 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 <literal>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 <literal>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 <literal>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 <literal>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 + <productname>PostgreSQL</> were to crash, but not if the standby + suffers an operating-system-level crash. + </para> + <para> + 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 <literal>local</> is available for transactions that + setting <literal>local</> is available for transactions that wish to wait for local flush to disk, but not synchronous replication. - If <varname>synchronous_standby_names</> is not set, <literal>on</>, - <literal>remote_write</> and <literal>local</> provide the same - synchronization level; transaction commit only waits for local flush. + If <varname>synchronous_standby_names</> is not set, the settings + <literal>on</>, <literal>remote_write</> and <literal>local</> all + provide the same synchronization level: transaction commits only wait + for local flush to disk. </para> <para> This parameter can be changed at any time; the behavior for any |