Set fallback_application_name for a walreceiver to cluster_name

Started by Peter Eisentrautalmost 7 years ago3 messages
#1Peter Eisentraut
peter.eisentraut@2ndquadrant.com
2 attachment(s)

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]</messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com&gt;, this doesn't allow dropping the
explicit application_name assignments in tests yet, but it's part of the
path to get there.

[0]: </messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com&gt;
</messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com&gt;

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachments:

0001-Set-fallback_application_name-for-a-walreceiver-to-c.patchtext/plain; charset=UTF-8; name=0001-Set-fallback_application_name-for-a-walreceiver-to-c.patch; x-mac-creator=0; x-mac-type=0Download
From b2901f54e943f6b609a93890c682aa9cf416e3c1 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@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

0002-Set-cluster_name-for-PostgresNode.pm-instances.patchtext/plain; charset=UTF-8; name=0002-Set-cluster_name-for-PostgresNode.pm-instances.patch; x-mac-creator=0; x-mac-type=0Download
From a332a82d1f7554f1b81fe4d59f3f9aea27bf4c0e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@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

#2Euler Taveira
euler@timbira.com.br
In reply to: Peter Eisentraut (#1)
Re: Set fallback_application_name for a walreceiver to cluster_name

Em sex, 8 de fev de 2019 às 05:16, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> escreveu:

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.

Although standby identification could be made by client_addr in
pg_stat_activity, it could be useful in multiple clusters in the same
host. Since it is a fallback application name, it can be overridden by
an application_name in primary_conninfo parameter.

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.

I tested it and both patches work as described. Passes all tests. Doc
describes the proposed feature. Doc builds without errors.

--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

#3Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Euler Taveira (#2)
Re: Set fallback_application_name for a walreceiver to cluster_name

On 2019-02-21 01:36, Euler Taveira wrote:

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.

Although standby identification could be made by client_addr in
pg_stat_activity, it could be useful in multiple clusters in the same
host. Since it is a fallback application name, it can be overridden by
an application_name in primary_conninfo parameter.

Yeah, plus that doesn't help with 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.

I tested it and both patches work as described. Passes all tests. Doc
describes the proposed feature. Doc builds without errors.

Committed, thanks!

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services