@@ -2571,14 +2571,26 @@ include_dir 'conf.d'
2571
2571
</term>
2572
2572
<listitem>
2573
2573
<para>
2574
- Specifies whether transaction commit will wait for WAL records
2575
- to be written to disk before the command returns a <quote>success</quote>
2576
- indication to the client. Valid values are <literal>on</literal>,
2577
- <literal>remote_apply</literal>, <literal>remote_write</literal>, <literal>local</literal>,
2578
- and <literal>off</literal>. The default, and safe, setting
2579
- is <literal>on</literal>. When <literal>off</literal>, there can be a delay between
2580
- when success is reported to the client and when the transaction is
2581
- really guaranteed to be safe against a server crash. (The maximum
2574
+ Specifies how much WAL processing must complete before
2575
+ the database server returns a <quote>success</quote>
2576
+ indication to the client. Valid values are
2577
+ <literal>remote_apply</literal>, <literal>on</literal>
2578
+ (the default), <literal>remote_write</literal>,
2579
+ <literal>local</literal>, and <literal>off</literal>.
2580
+ </para>
2581
+
2582
+ <para>
2583
+ If <varname>synchronous_standby_names</varname> is empty,
2584
+ the only meaningful settings are <literal>on</literal> and
2585
+ <literal>off</literal>; <literal>remote_apply</literal>,
2586
+ <literal>remote_write</literal> and <literal>local</literal>
2587
+ all provide the same local synchronization level
2588
+ as <literal>on</literal>. The local behavior of all
2589
+ non-<literal>off</literal> modes is to wait for local flush of WAL
2590
+ to disk. In <literal>off</literal> mode, there is no waiting,
2591
+ so there can be a delay between when success is reported to the
2592
+ client and when the transaction is later guaranteed to be safe
2593
+ against a server crash. (The maximum
2582
2594
delay is three times <xref linkend="guc-wal-writer-delay"/>.) Unlike
2583
2595
<xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal>
2584
2596
does not create any risk of database inconsistency: an operating
@@ -2590,38 +2602,40 @@ include_dir 'conf.d'
2590
2602
exact certainty about the durability of a transaction. For more
2591
2603
discussion see <xref linkend="wal-async-commit"/>.
2592
2604
</para>
2605
+
2593
2606
<para>
2594
- If <xref linkend="guc-synchronous-standby-names"/> is non-empty, this
2595
- parameter also controls whether or not transaction commits will wait
2596
- for their WAL records to be replicated to the standby server(s).
2597
- When set to <literal>on</literal>, commits will wait until replies
2607
+ If <xref linkend="guc-synchronous-standby-names"/> is non-empty,
2608
+ <varname>synchronous_commit</varname> also controls whether
2609
+ transaction commits will wait for their WAL records to be
2610
+ processed on the standby server(s).
2611
+ </para>
2612
+
2613
+ <para>
2614
+ When set to <literal>remote_apply</literal>, commits will wait
2615
+ until replies from the current synchronous standby(s) indicate they
2616
+ have received the commit record of the transaction and applied
2617
+ it, so that it has become visible to queries on the standby(s),
2618
+ and also written to durable storage on the standbys. This will
2619
+ cause much larger commit delays than previous settings since
2620
+ it waits for WAL replay. When set to <literal>on</literal>,
2621
+ commits wait until replies
2598
2622
from the current synchronous standby(s) indicate they have received
2599
- the commit record of the transaction and flushed it todisk . This
2623
+ the commit record of the transaction and flushed it todurable storage . This
2600
2624
ensures the transaction will not be lost unless both the primary and
2601
2625
all synchronous standbys suffer corruption of their database storage.
2602
- When set to <literal>remote_apply</literal>, commits will wait until replies
2603
- from the current synchronous standby(s) indicate they have received the
2604
- commit record of the transaction and applied it, so that it has become
2605
- visible to queries on the standby(s).
2606
2626
When set to <literal>remote_write</literal>, commits will wait until replies
2607
2627
from the current synchronous standby(s) indicate they have
2608
- received the commit record of the transaction and written it out to
2609
- their operating system. This setting is sufficient to
2610
- ensure data preservation even if a standby instance of
2611
- <productname>PostgreSQL</productname> were to crash, but not if the standby
2612
- suffers an operating-system-level crash, since the data has not
2628
+ received the commit record of the transaction and written it to
2629
+ their file systems. This setting ensures data preservation if a standby instance of
2630
+ <productname>PostgreSQL</productname> crashes, but not if the standby
2631
+ suffers an operating-system-level crash because the data has not
2613
2632
necessarily reached durable storage on the standby.
2614
- Finally, the setting <literal>local</literal> causes commits to wait for
2615
- local flush to disk, but not for replication. This isnot usually
2633
+ The setting <literal>local</literal> causes commits to wait for
2634
+ local flush to disk, but not for replication. This is usually not
2616
2635
desirable when synchronous replication is in use, but is provided for
2617
2636
completeness.
2618
2637
</para>
2619
- <para>
2620
- If <varname>synchronous_standby_names</varname> is empty, the settings
2621
- <literal>on</literal>, <literal>remote_apply</literal>, <literal>remote_write</literal>
2622
- and <literal>local</literal> all provide the same synchronization level:
2623
- transaction commits only wait for local flush to disk.
2624
- </para>
2638
+
2625
2639
<para>
2626
2640
This parameter can be changed at any time; the behavior for any
2627
2641
one transaction is determined by the setting in effect when it
@@ -2631,6 +2645,76 @@ include_dir 'conf.d'
2631
2645
asynchronously when the default is the opposite, issue <command>SET
2632
2646
LOCAL synchronous_commit TO OFF</command> within the transaction.
2633
2647
</para>
2648
+
2649
+ <para>
2650
+ <xref linkend="synchronous-commit-matrix"/> summarizes the
2651
+ capabilities of the <varname>synchronous_commit</varname> settings.
2652
+ </para>
2653
+
2654
+ <table id="synchronous-commit-matrix">
2655
+ <title>synchronous_commit Modes</title>
2656
+ <tgroup cols="5">
2657
+ <colspec colname="col1" colwidth="1.1*"/>
2658
+ <colspec colname="col2" colwidth="1*"/>
2659
+ <colspec colname="col3" colwidth="1*"/>
2660
+ <colspec colname="col4" colwidth="1*"/>
2661
+ <colspec colname="col5" colwidth="1*"/>
2662
+ <thead>
2663
+ <row>
2664
+ <entry>synchronous_commit setting</entry>
2665
+ <entry>local durable commit</entry>
2666
+ <entry>standby durable commit after PG crash</entry>
2667
+ <entry>standby durable commit after OS crash</entry>
2668
+ <entry>standby query consistency</entry>
2669
+ </row>
2670
+ </thead>
2671
+
2672
+ <tbody>
2673
+
2674
+ <row>
2675
+ <entry>remote_apply</entry>
2676
+ <entry align="center">•</entry>
2677
+ <entry align="center">•</entry>
2678
+ <entry align="center">•</entry>
2679
+ <entry align="center">•</entry>
2680
+ </row>
2681
+
2682
+ <row>
2683
+ <entry>on</entry>
2684
+ <entry align="center">•</entry>
2685
+ <entry align="center">•</entry>
2686
+ <entry align="center">•</entry>
2687
+ <entry align="center"></entry>
2688
+ </row>
2689
+
2690
+ <row>
2691
+ <entry>remote_write</entry>
2692
+ <entry align="center">•</entry>
2693
+ <entry align="center">•</entry>
2694
+ <entry align="center"></entry>
2695
+ <entry align="center"></entry>
2696
+ </row>
2697
+
2698
+ <row>
2699
+ <entry>local</entry>
2700
+ <entry align="center">•</entry>
2701
+ <entry align="center"></entry>
2702
+ <entry align="center"></entry>
2703
+ <entry align="center"></entry>
2704
+ </row>
2705
+
2706
+ <row>
2707
+ <entry>off</entry>
2708
+ <entry align="center"></entry>
2709
+ <entry align="center"></entry>
2710
+ <entry align="center"></entry>
2711
+ <entry align="center"></entry>
2712
+ </row>
2713
+
2714
+ </tbody>
2715
+ </tgroup>
2716
+ </table>
2717
+
2634
2718
</listitem>
2635
2719
</varlistentry>
2636
2720