By default, the fallback_application_name for a physical walreceiver is
"walreceiver". This means that multiple standbys cannot be
distinguished easily on a primary, for example in pg_stat_activity or
synchronous_standby_names.
I propose, if cluster_name is set, use that for
fallback_application_name in the walreceiver. (If it's not set, it
remains "walreceiver".) If someone set cluster_name to identify their
instance, we might as well use that by default to identify the node
remotely as well. It's still possible to specify another
application_name in primary_conninfo explicitly.
Then you can do something like cluster_name = 'nodeN' and
synchronous_standby_names = 'node1,node2,node3' without any further
fiddling with application_name.
See attached patches.
I also included a patch to set cluster_name in PostgresNode.pm
instances, for easier identification and a bit of minimal testing.
Because of the issues described in [0], this doesn't allow dropping the
explicit application_name assignments in tests yet, but it's part of the
path to get there.
[0]:
<https://www.postgresql.org/message-id/33383613-690e-6f1b-d5ba-4957ff40f...@2ndquadrant.com>
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From b2901f54e943f6b609a93890c682aa9cf416e3c1 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Fri, 8 Feb 2019 08:17:21 +0100
Subject: [PATCH 1/2] Set fallback_application_name for a walreceiver to
cluster_name
By default, the fallback_application_name for a physical walreceiver
is "walreceiver". This means that multiple standbys cannot be
distinguished easily on a primary, for example in pg_stat_activity or
synchronous_standby_names.
If cluster_name is set, use that for fallback_application_name in the
walreceiver. (If it's not set, it remains "walreceiver".) If someone
set cluster_name to identify their instance, we might as well use that
by default to identify the node remotely as well. It's still possible
to specify another application_name in primary_conninfo explicitly.
---
doc/src/sgml/config.sgml | 14 +++++++++++---
src/backend/replication/walreceiver.c | 2 +-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 7e208a4b81..cab858b54e 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3659,7 +3659,8 @@ <title>Master Server</title>
<varname>application_name</varname> setting of the standby, as set in
the
standby's connection information. In case of a physical replication
standby, this should be set in the <varname>primary_conninfo</varname>
- setting; the default is <literal>walreceiver</literal>.
+ setting; the default is the setting of <xref
linkend="guc-cluster-name"/>
+ if set, else <literal>walreceiver</literal>.
For logical replication, this can be set in the connection
information of the subscription, and it defaults to the
subscription name. For other replication stream consumers,
@@ -6560,8 +6561,15 @@ <title>Process Title</title>
</term>
<listitem>
<para>
- Sets the cluster name that appears in the process title for all
- server processes in this cluster. The name can be any string of less
+ Sets a name that identifies this database cluster (instance) for
+ various purposes. The cluster name appears in the process title for
+ all server processes in this cluster. Moreover, it is the default
+ application name for a standby connection (see <xref
+ linkend="guc-synchronous-standby-names"/>.)
+ </para>
+
+ <para>
+ The name can be any string of less
than <symbol>NAMEDATALEN</symbol> characters (64 characters in a
standard
build). Only printable ASCII characters may be used in the
<varname>cluster_name</varname> value. Other characters will be
diff --git a/src/backend/replication/walreceiver.c
b/src/backend/replication/walreceiver.c
index 2e90944ad5..9eaaa8ff50 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -293,7 +293,7 @@ WalReceiverMain(void)
/* Establish the connection to the primary for XLOG streaming */
EnableWalRcvImmediateExit();
- wrconn = walrcv_connect(conninfo, false, "walreceiver", &err);
+ wrconn = walrcv_connect(conninfo, false, cluster_name[0] ? cluster_name
: "walreceiver", &err);
if (!wrconn)
ereport(ERROR,
(errmsg("could not connect to the primary
server: %s", err)));
base-commit: 3677a0b26bb2f3f72d16dc7fa6f34c305badacce
--
2.20.1
From a332a82d1f7554f1b81fe4d59f3f9aea27bf4c0e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Fri, 8 Feb 2019 08:38:54 +0100
Subject: [PATCH 2/2] Set cluster_name for PostgresNode.pm instances
This can help identifying test instances more easily at run time, and
it also provides some minimal test coverage for the cluster_name
feature.
---
src/test/perl/PostgresNode.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index 8a2c6fc122..0634aefd20 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -700,8 +700,10 @@ sub start
my $name = $self->name;
BAIL_OUT("node \"$name\" is already running") if defined $self->{_pid};
print("### Starting node \"$name\"\n");
+ # Note: We set the cluster_name here, not in postgresql.conf (in
+ # sub init) so that it does not get copied to standbys.
my $ret = TestLib::system_log('pg_ctl', '-D', $self->data_dir, '-l',
- $self->logfile, 'start');
+ $self->logfile, '-o', "--cluster-name=$name", 'start');
if ($ret != 0)
{
--
2.20.1
