pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Set fallback_application_name for a walreceiver to cluster_name 3+ messages / 2 participants [nested] [flat]
* Set fallback_application_name for a walreceiver to cluster_name @ 2019-02-08 08:16 Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 0 siblings, 1 reply; 3+ messages in thread From: Peter Eisentraut @ 2019-02-08 08:16 UTC (permalink / raw) To: pgsql-hackers 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-4957ff40f6ce@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 <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 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 Attachments: [text/plain] 0001-Set-fallback_application_name-for-a-walreceiver-to-c.patch (3.3K, ../../1257eaee-4874-e791-e83a-46720c72cac7@2ndquadrant.com/2-0001-Set-fallback_application_name-for-a-walreceiver-to-c.patch) download | inline diff: 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 [text/plain] 0002-Set-cluster_name-for-PostgresNode.pm-instances.patch (1.1K, ../../1257eaee-4874-e791-e83a-46720c72cac7@2ndquadrant.com/3-0002-Set-cluster_name-for-PostgresNode.pm-instances.patch) download | inline diff: 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Set fallback_application_name for a walreceiver to cluster_name @ 2019-02-21 00:36 Euler Taveira <euler@timbira.com.br> parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 0 siblings, 1 reply; 3+ messages in thread From: Euler Taveira @ 2019-02-21 00:36 UTC (permalink / raw) To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Set fallback_application_name for a walreceiver to cluster_name @ 2019-02-27 10:02 Peter Eisentraut <peter.eisentraut@2ndquadrant.com> parent: Euler Taveira <euler@timbira.com.br> 0 siblings, 0 replies; 3+ messages in thread From: Peter Eisentraut @ 2019-02-27 10:02 UTC (permalink / raw) To: Euler Taveira <euler@timbira.com.br>; +Cc: pgsql-hackers 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2019-02-27 10:02 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-02-08 08:16 Set fallback_application_name for a walreceiver to cluster_name Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 2019-02-21 00:36 ` Euler Taveira <euler@timbira.com.br> 2019-02-27 10:02 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox