diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/config.sgml | 18 | ||||
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 16 |
2 files changed, 26 insertions, 8 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index e55b5035e26..309b6a54615 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1560,7 +1560,7 @@ 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</>, + indication to the client. Valid values are <literal>on</>, <literal>write</>, <literal>local</>, and <literal>off</>. The default, and safe, value is <literal>on</>. When <literal>off</>, there can be a delay between when success is reported to the client and when the transaction is @@ -1580,11 +1580,19 @@ SET ENABLE_SEQSCAN TO OFF; 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. The commit wait will last until a reply from - the current synchronous standby indicates it has written the commit - record of the transaction to durable storage. If synchronous + to the standby server. When <literal>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 replication is in use, it will normally be sensible either to wait - both for WAL records to reach both the local and remote disks, or + for both local flush and replication of WAL records, or to allow the transaction to commit asynchronously. However, the special value <literal>local</> is available for transactions that wish to wait for local flush to disk, but not synchronous replication. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index c5db6ef01f8..ed34dac023d 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1011,6 +1011,16 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' </para> <para> + Setting <varname>synchronous_commit</> to <literal>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 <literal>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 database of the primary gets corrupted at the same time. + </para> + + <para> Users will stop waiting if a fast shutdown is requested. However, as when using asynchronous replication, the server will does not fully shutdown until all outstanding WAL records are transferred to the currently @@ -1065,13 +1075,13 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' <para> Commits made when <varname>synchronous_commit</> is set to <literal>on</> - will wait until the sync standby responds. The response may never occur - if the last, or only, standby should crash. + or <literal>write</> will wait until the synchronous standby responds. The response + may never occur if the last, or only, standby should crash. </para> <para> The best solution for avoiding data loss is to ensure you don't lose - your last remaining sync standby. This can be achieved by naming multiple + your last remaining synchronous standby. This can be achieved by naming multiple potential synchronous standbys using <varname>synchronous_standby_names</>. The first named standby will be used as the synchronous standby. Standbys listed after this will take over the role of synchronous standby if the |