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.

2 files changed, 21 insertions, 69 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b2c5e4d5dd..575168ed23 100644
--- 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 acdbf1e230..959ca78a1e 100644
--- 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);