@@ -2703,14 +2703,26 @@ include_dir 'conf.d'
2703
2703
</term>
2704
2704
<listitem>
2705
2705
<para>
2706
- Specifies whether transaction commit will wait for WAL records
2707
- to be written to disk before the command returns a <quote>success</quote>
2708
- indication to the client. Valid values are <literal>on</literal>,
2709
- <literal>remote_apply</literal>, <literal>remote_write</literal>, <literal>local</literal>,
2710
- and <literal>off</literal>. The default, and safe, setting
2711
- is <literal>on</literal>. When <literal>off</literal>, there can be a delay between
2712
- when success is reported to the client and when the transaction is
2713
- really guaranteed to be safe against a server crash. (The maximum
2706
+ Specifies how much WAL processing must complete before
2707
+ the database server returns a <quote>success</quote>
2708
+ indication to the client. Valid values are
2709
+ <literal>remote_apply</literal>, <literal>on</literal>
2710
+ (the default), <literal>remote_write</literal>,
2711
+ <literal>local</literal>, and <literal>off</literal>.
2712
+ </para>
2713
+
2714
+ <para>
2715
+ If <varname>synchronous_standby_names</varname> is empty,
2716
+ the only meaningful settings are <literal>on</literal> and
2717
+ <literal>off</literal>; <literal>remote_apply</literal>,
2718
+ <literal>remote_write</literal> and <literal>local</literal>
2719
+ all provide the same local synchronization level
2720
+ as <literal>on</literal>. The local behavior of all
2721
+ non-<literal>off</literal> modes is to wait for local flush of WAL
2722
+ to disk. In <literal>off</literal> mode, there is no waiting,
2723
+ so there can be a delay between when success is reported to the
2724
+ client and when the transaction is later guaranteed to be safe
2725
+ against a server crash. (The maximum
2714
2726
delay is three times <xref linkend="guc-wal-writer-delay"/>.) Unlike
2715
2727
<xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal>
2716
2728
does not create any risk of database inconsistency: an operating
@@ -2722,38 +2734,40 @@ include_dir 'conf.d'
2722
2734
exact certainty about the durability of a transaction. For more
2723
2735
discussion see <xref linkend="wal-async-commit"/>.
2724
2736
</para>
2737
+
2725
2738
<para>
2726
- If <xref linkend="guc-synchronous-standby-names"/> is non-empty, this
2727
- parameter also controls whether or not transaction commits will wait
2728
- for their WAL records to be replicated to the standby server(s).
2729
- When set to <literal>on</literal>, commits will wait until replies
2739
+ If <xref linkend="guc-synchronous-standby-names"/> is non-empty,
2740
+ <varname>synchronous_commit</varname> also controls whether
2741
+ transaction commits will wait for their WAL records to be
2742
+ processed on the standby server(s).
2743
+ </para>
2744
+
2745
+ <para>
2746
+ When set to <literal>remote_apply</literal>, commits will wait
2747
+ until replies from the current synchronous standby(s) indicate they
2748
+ have received the commit record of the transaction and applied
2749
+ it, so that it has become visible to queries on the standby(s),
2750
+ and also written to durable storage on the standbys. This will
2751
+ cause much larger commit delays than previous settings since
2752
+ it waits for WAL replay. When set to <literal>on</literal>,
2753
+ commits wait until replies
2730
2754
from the current synchronous standby(s) indicate they have received
2731
- the commit record of the transaction and flushed it to disk . This
2755
+ the commit record of the transaction and flushed it to durable storage . This
2732
2756
ensures the transaction will not be lost unless both the primary and
2733
2757
all synchronous standbys suffer corruption of their database storage.
2734
- When set to <literal>remote_apply</literal>, commits will wait until replies
2735
- from the current synchronous standby(s) indicate they have received the
2736
- commit record of the transaction and applied it, so that it has become
2737
- visible to queries on the standby(s).
2738
2758
When set to <literal>remote_write</literal>, commits will wait until replies
2739
2759
from the current synchronous standby(s) indicate they have
2740
- received the commit record of the transaction and written it out to
2741
- their operating system. This setting is sufficient to
2742
- ensure data preservation even if a standby instance of
2743
- <productname>PostgreSQL</productname> were to crash, but not if the standby
2744
- suffers an operating-system-level crash, since the data has not
2760
+ received the commit record of the transaction and written it to
2761
+ their file systems. This setting ensures data preservation if a standby instance of
2762
+ <productname>PostgreSQL</productname> crashes, but not if the standby
2763
+ suffers an operating-system-level crash because the data has not
2745
2764
necessarily reached durable storage on the standby.
2746
- Finally, the setting <literal>local</literal> causes commits to wait for
2747
- local flush to disk, but not for replication. This is not usually
2765
+ The setting <literal>local</literal> causes commits to wait for
2766
+ local flush to disk, but not for replication. This is usually not
2748
2767
desirable when synchronous replication is in use, but is provided for
2749
2768
completeness.
2750
2769
</para>
2751
- <para>
2752
- If <varname>synchronous_standby_names</varname> is empty, the settings
2753
- <literal>on</literal>, <literal>remote_apply</literal>, <literal>remote_write</literal>
2754
- and <literal>local</literal> all provide the same synchronization level:
2755
- transaction commits only wait for local flush to disk.
2756
- </para>
2770
+
2757
2771
<para>
2758
2772
This parameter can be changed at any time; the behavior for any
2759
2773
one transaction is determined by the setting in effect when it
@@ -2763,6 +2777,76 @@ include_dir 'conf.d'
2763
2777
asynchronously when the default is the opposite, issue <command>SET
2764
2778
LOCAL synchronous_commit TO OFF</command> within the transaction.
2765
2779
</para>
2780
+
2781
+ <para>
2782
+ <xref linkend="synchronous-commit-matrix"/> summarizes the
2783
+ capabilities of the <varname>synchronous_commit</varname> settings.
2784
+ </para>
2785
+
2786
+ <table id="synchronous-commit-matrix">
2787
+ <title>synchronous_commit Modes</title>
2788
+ <tgroup cols="5">
2789
+ <colspec colname="col1" colwidth="1.1*"/>
2790
+ <colspec colname="col2" colwidth="1*"/>
2791
+ <colspec colname="col3" colwidth="1*"/>
2792
+ <colspec colname="col4" colwidth="1*"/>
2793
+ <colspec colname="col5" colwidth="1*"/>
2794
+ <thead>
2795
+ <row>
2796
+ <entry>synchronous_commit setting</entry>
2797
+ <entry>local durable commit</entry>
2798
+ <entry>standby durable commit after PG crash</entry>
2799
+ <entry>standby durable commit after OS crash</entry>
2800
+ <entry>standby query consistency</entry>
2801
+ </row>
2802
+ </thead>
2803
+
2804
+ <tbody>
2805
+
2806
+ <row>
2807
+ <entry>remote_apply</entry>
2808
+ <entry align="center">•</entry>
2809
+ <entry align="center">•</entry>
2810
+ <entry align="center">•</entry>
2811
+ <entry align="center">•</entry>
2812
+ </row>
2813
+
2814
+ <row>
2815
+ <entry>on</entry>
2816
+ <entry align="center">•</entry>
2817
+ <entry align="center">•</entry>
2818
+ <entry align="center">•</entry>
2819
+ <entry align="center"></entry>
2820
+ </row>
2821
+
2822
+ <row>
2823
+ <entry>remote_write</entry>
2824
+ <entry align="center">•</entry>
2825
+ <entry align="center">•</entry>
2826
+ <entry align="center"></entry>
2827
+ <entry align="center"></entry>
2828
+ </row>
2829
+
2830
+ <row>
2831
+ <entry>local</entry>
2832
+ <entry align="center">•</entry>
2833
+ <entry align="center"></entry>
2834
+ <entry align="center"></entry>
2835
+ <entry align="center"></entry>
2836
+ </row>
2837
+
2838
+ <row>
2839
+ <entry>off</entry>
2840
+ <entry align="center"></entry>
2841
+ <entry align="center"></entry>
2842
+ <entry align="center"></entry>
2843
+ <entry align="center"></entry>
2844
+ </row>
2845
+
2846
+ </tbody>
2847
+ </tgroup>
2848
+ </table>
2849
+
2766
2850
</listitem>
2767
2851
</varlistentry>
2768
2852
0 commit comments