Hello, now the synchronous_standby_names can teach to ensure more
then one synchronous standbys. But the doc for it seems assuming
only one synchronous standby.
> There is no mechanism to enforce uniqueness. In case of
> duplicates one of the matching standbys will be considered as
> higher priority, though exactly which one is indeterminate.
The patch attatched edits the above to the following.
> There is no mechanism to enforce uniqueness. In case of
> duplicates some of the matching standbys will be considered as
> higher priority, though they are chosen in an indeterminate way.
Is this makes sense?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f9ba148..7b2edbe 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3028,9 +3028,9 @@ include_dir 'conf.d' The name of a standby server for this purpose is the
<varname>application_name</>setting of the standby, as set in the <varname>primary_conninfo</> of the standby's
WALreceiver. There is
- no mechanism to enforce uniqueness. In case of duplicates one of the
- matching standbys will be considered as higher priority, though
- exactly which one is indeterminate.
+ no mechanism to enforce uniqueness. In case of duplicates some of the
+ matching standbys will be considered as higher priority, though they
+ are chosen in an indeterminate way. The special entry <literal>*</> matches any
<varname>application_name</>,including the default application name of <literal>walreceiver</>.
