Remove warning about num_sync being too large in synchronous_standby_names.

If we're not going to reject such setups entirely, throwing a WARNING in
check_synchronous_standby_names() is unhelpful, because it will cause the
warning to be logged again every time the postmaster receives SIGHUP.
Per discussion, just remove the warning.

In passing, improve the documentation for synchronous_commit, which had not
gotten the word that now there can be more than one synchronous standby.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b2c5e4d5dd2fed658a3330bd770c1a03b15ae7a0..575168ed235c0ebc5869221ee5da960f9176ac1e 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2220,7 +2220,7 @@ include_dir 'conf.d'
         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>remote_apply</>, <literal>local</>,
+        <literal>remote_apply</>, <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
@@ -2237,36 +2237,33 @@ include_dir 'conf.d'
         discussion see <xref linkend="wal-async-commit">.
        </para>
        <para>
-        If <xref linkend="guc-synchronous-standby-names"> is set, this
+        If <xref linkend="guc-synchronous-standby-names"> is non-empty, this
         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
+        for their WAL records to be replicated to the standby server(s).
+        When set to <literal>on</>, commits will wait until replies
+        from the current synchronous standby(s) indicate they have 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_apply</>, commits will wait until a reply
-        from the current synchronous standby indicates it has received the
+        ensures the transaction will not be lost unless both the primary and
+        all synchronous standbys suffer corruption of their database storage.
+        When set to <literal>remote_apply</>, commits will wait until replies
+        from the current synchronous standby(s) indicate they have received the
         commit record of the transaction and applied it, so that it has become
-        visible to queries.
-        When set to <literal>remote_write</>, commits will wait
-        until a reply from the current synchronous standby indicates it has
+        visible to queries on the standby(s).
+        When set to <literal>remote_write</>, commits will wait until replies
+        from the current synchronous standby(s) indicate they have
         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
+        their operating system. This setting is sufficient to
+        ensure data preservation even if a standby instance of
         <productname>PostgreSQL</> were to crash, but not if the standby
-        suffers an operating-system-level crash.
+        suffers an operating-system-level crash, since the data has not
+        necessarily reached stable storage on the standby.
+        Finally, the setting <literal>local</> causes commits to wait for
+        local flush to disk, but not for replication.  This is not usually
+        desirable when synchronous replication is in use, but is provided for
+        completeness.
        </para>
        <para>
-        When synchronous
-        replication is in use, it will normally be sensible either to wait
-        for both local flush to disk and replication of WAL records, or
-        to allow the transaction to commit asynchronously.  However, the
-        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, the settings
+        If <varname>synchronous_standby_names</> is empty, the settings
         <literal>on</>, <literal>remote_apply</>, <literal>remote_write</>
         and <literal>local</> all provide the same synchronization level:
         transaction commits only wait for local flush to disk.

diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c
index acdbf1e230c57a2281b372fc0bc379010477bbc6..959ca78a1efeb018beab95c9dcfa29597392f740 100644 (file)
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -929,51 +929,6 @@ check_synchronous_standby_names(char **newval, void **extra, GucSource source)
            return false;
        }
 
-       /*
-        * Warn if num_sync exceeds the number of names of potential sync
-        * standbys. This setting doesn't make sense in most cases because it
-        * implies that enough number of sync standbys will not appear, which
-        * makes transaction commits wait for sync replication infinitely.
-        *
-        * If there are more than one standbys having the same name and
-        * priority, we can see enough sync standbys to complete transaction
-        * commits. However it's not recommended to run multiple standbys with
-        * the same priority because we cannot gain full control of the
-        * selection of sync standbys from them.
-        *
-        * OTOH, that setting is OK if we understand the above problem
-        * regarding the selection of sync standbys and intentionally specify *
-        * to match all the standbys.
-        */
-       if (syncrep_parse_result->num_sync > syncrep_parse_result->nmembers)
-       {
-           const char *standby_name;
-           int         i;
-           bool        has_asterisk = false;
-
-           standby_name = syncrep_parse_result->member_names;
-           for (i = 1; i <= syncrep_parse_result->nmembers; i++)
-           {
-               if (strcmp(standby_name, "*") == 0)
-               {
-                   has_asterisk = true;
-                   break;
-               }
-               standby_name += strlen(standby_name) + 1;
-           }
-
-           /*
-            * Only the postmaster warns about this inappropriate setting to
-            * avoid cluttering the log.
-            */
-           if (!has_asterisk && !IsUnderPostmaster)
-               ereport(WARNING,
-                       (errmsg("configured number of synchronous standbys (%d) exceeds the number of names of potential synchronous ones (%d)",
-                               syncrep_parse_result->num_sync,
-                               syncrep_parse_result->nmembers),
-                        errhint("Specify more names of potential synchronous standbys in synchronous_standby_names.")));
-       }
-
        /* GUC extra value must be malloc'd, not palloc'd */
        pconf = (SyncRepConfigData *)
            malloc(syncrep_parse_result->config_size);