@@ -2703,14 +2703,26 @@ include_dir 'conf.d'
27032703 </term>
27042704 <listitem>
27052705 <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
27142726 delay is three times <xref linkend="guc-wal-writer-delay"/>.) Unlike
27152727 <xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal>
27162728 does not create any risk of database inconsistency: an operating
@@ -2722,38 +2734,40 @@ include_dir 'conf.d'
27222734 exact certainty about the durability of a transaction. For more
27232735 discussion see <xref linkend="wal-async-commit"/>.
27242736 </para>
2737+
27252738 <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
27302754 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
27322756 ensures the transaction will not be lost unless both the primary and
27332757 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).
27382758 When set to <literal>remote_write</literal>, commits will wait until replies
27392759 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
27452764 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
27482767 desirable when synchronous replication is in use, but is provided for
27492768 completeness.
27502769 </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+
27572771 <para>
27582772 This parameter can be changed at any time; the behavior for any
27592773 one transaction is determined by the setting in effect when it
@@ -2763,6 +2777,76 @@ include_dir 'conf.d'
27632777 asynchronously when the default is the opposite, issue <command>SET
27642778 LOCAL synchronous_commit TO OFF</command> within the transaction.
27652779 </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+
27662850 </listitem>
27672851 </varlistentry>
27682852
0 commit comments